University of Pennsylvania Technical Report MS-CIS-13-10 



Closed Type Families with Overlapping 
Equations (Extended version) 

Richard A. Eisenberg Dimitrios Vytiniotis Stephanie Weirich 

University of Pennsylvania Simon Peyton Jones University of Pennsylvania 

eir@cis.upenn.edu Microsoft Research Cambridge sweirich@cis.upenn.edu 

{dimitris,simonpj}@microsoft.com 



Abstract 

Open, type-level functions are a recent innovation in Haskell that 
move Haskell towards the expressiveness of dependent types, while 
retaining the look and feel of a practical programming language. 
This paper shows how to increase expressiveness still further, by 
adding closed type functions whose equations may overlap, and 
may have non-linear patterns over an open type universe. Although 
practically useful and simple to implement, these features go be- 
yond conventional dependent type theory in some respects, and 
have a subtle metatheory. 

Categories and Subject Descriptors F.3.3 [Logics and Mean- 
ings of Programs]: Studies of Program Constructs — type structure; 
D.3.3 [Programming Languages]: Language Constructs and Fea- 
tures; F.4.2 [Mathematical Logic and Formal Languages]: Gram- 
mars and Other Rewriting Systems — parallel rewriting systems 

General Terms Design, Languages, Theory 

Keywords Type families; Type-level computation; Haskell; Sys- 
tem FC 

1. Introduction 

Type families are a relatively recent extension to Haskell that allows 
the programmer to express type-level computation (Chakravarty 
et al. 2005). For example, one can say 

type family Elt (a :: *) :: * 

type instance Elt ByteString = Word8 

type instance Elt [b] = b 

The first line declares the type family Elt and gives its kind; the 
second and third are two independent declarations that give two 
equations for Elt. Now the types (Elt ByteString) and Word8 are 
considered equivalent by the type inference engine, and likewise 
(Elt [Int]) and Int. Type families have proved to be a popular 
feature in Haskell, dovetailing particularly nicely with Haskell's 
type classes. Type families are naturally partial and open. For 
example, there is no equation for Elt Char above, so Elt Char 
will never be equal to any other type. On the other hand, the author 
of a new library is free to add a new instance, such as this one: 

type instance Elt (Set b) = b 

However, not all type-level functions can be defined by open type 
families. An important example is the equality function, which 
determines whether two types can be shown equal at compile- 
time: 1 



1 Here we use datatype promotion, allowing data types like Bool, and lists, 
to be used as kinds (Yorgey et al. 2012). 



type family Equal a b :: Bool 

type instance Equal a a — True — Instance (A) 

type instance Equal a b = False — Instance (B) 

The programmer intends these equations to be read top-to-bottom, 
like a term-level function definition in Haskell. However, because 
GHC's current type families are open, they must be defined by inde- 
pendent, un-ordered type instance equations. The two equations 
overlap, so they are rightly rejected lest they be used to deduce 
unsound type equalities. For example, we could reduce the type 
Equal Int Int to both True and False, since both patterns match. 

Yet equality is a well-defined function, and a useful one too, as 
we discuss in Section 2. To fix this omission we introduce closed 
type families with ordered equations, thus: 

type family Equal a b :: Bool where 
Equal a a — True 
Equal a b — False 

Now all the equations for the type family are given together, and 
can be read top-to-bottom. However, behind this simple idea lie 
a number of complexities. In this paper we describe these pitfalls 
and their sometimes non-obvious solutions. We make the following 
contributions: 

• We introduce closed type families with overlapping equations, 
and show how they can readily express programs that were 
previously inexpressible or required indirect encodings (Sec- 
tion 2). 

• Our system supports non-linear left-hand sides, such as that for 
Equal above, where the variable a is repeated in the first equa- 
tion. It also supports coincident overlap, which allows some 
lightweight theorem-proving capability to be incorporated in 
the definitional equality of types (Section 3.4). 

• We give the subtle rules that govern type family simplifica- 
tion, including those that determine when a pattern cannot be 
matched by a type (Section 3). 

• We describe a typed core language that includes both open and 
closed type families (Section 4), and prove that it is type-safe, 
assuming that type families terminate (Section 5). We do that 
by establishing a consistency property of the type equations 
induced by type families. 

• We identify the complications for consistency that arise from 
non-terminating type families and we expose a subtle oversight 
in GHC's current rules for open type families in Section 6. 

• We have implemented closed type families in GHC as well as a 
number of case studies, such as the units package, an extensible 
framework for dimensional analysis, presented in Appendix A. 
Closed type families are available now in GHC 7.8. 
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In short, the programmer sees a simple, intuitive language fea- 
ture, but the design space (and its metatheory) is subtle. Although 
type families resemble the type-level computation and "large elim- 
inations" found in full-spectrum dependently-typed languages like 
Coq and Agda, there are important semantic and practical differ- 
ences. We discuss these in Section 8. 

2. Closed type families 

Haskell (in its implementation in GHC) has supported type families 
for several years. They were introduced to support associated types, 
a feature that Garcia et al.'s (2003) comparison between C++, 
Haskell, and ML, noted as a C++'s main superiority for generic 
programming. 

Type families were designed to dovetail smoothly with type 
classes. For example, the type function 2 Elt above could be used 
to specify the element type in a container class: 

class Container c where 
empty :: c 

member :: Elt c — > c — > Bool 

instance Container [a] where ... 
instance Container ByteString where ... 

New instances for Container can be defined as new types are 
introduced, often in different modules, and correspondingly new 
equations for Elt must be added too. Hence Elt must be open 
(that is, can be extended in modules that import it), and distributed 
(can be scattered over many different modules). This contrasts with 
term-level functions where we are required to define the function 
all in one place. 

The open, distributed nature of type families, typically associ- 
ated with classes, requires strong restrictions on overlap to maintain 
soundness. Consider 

type family Fab::* 

type instance F Int a = Bool 

type instance F a Bool = Char 

Now consider the type (F Int Bool). Using the first equation, this 
type is equal to Bool, but using the second it is equal to Char. So 
if we are not careful, we could pass a Bool to a function expecting 
a Char, which would be embarrassing. 

GHC therefore brutally insists that the left-hand sides of two 
type instance equations must not overlap (unify). (At least, unless 
the right-hand sides would then coincide; see Section 3.4.) 

2.1 Closed families: the basic idea 

As we saw in the Introduction, disallowing overlap means that use- 
ful, well-defined type-level functions, such as type level equality, 
cannot be expressed. Since openness is the root of the overlap prob- 
lem, it can be solved by defining the equations for the type family 
all in one place. We call this a closed type family and define it using 
a where clause on the function's original declaration. The equa- 
tions may overlap, and are matched top-to-bottom. For example: 

type family And (a :: Bool) (b :: Bool) :: Bool where 
And True True = True 
And a b = False 

Since the domain of And is closed and finite, it is natural to write 
all its equations in one place. Doing so directly expresses the fact 
that no further equations are expected. 

Although we have used overlap in this example, one can always 
write functions over finite domains without overlap: 



2 We use "type family" and "type function" interchangeably. 



type family And' (a :: Bool) (b :: Bool) :: Bool where 
And' True True — True 
And' False True = False 
And' True False — False 
And' False False = False 

Nevertheless, overlap is convenient for the programmer, mirrors 
what happens at the term level, avoids a polynomial blowup in 
program size, and is more efficient (for the type checker) to execute. 
Furthermore, when defined over an open kind, such as *, closed 
type families allow a programmer to express relationships (such 
as inequality of types — see Section 2.4) that are otherwise out of 
reach. 

2.2 Non-linear patterns 

Let us return to our equality function, which can now be defined 
thus: 

type family Equal (a :: *) (b :: *) :: Bool where 
Equal a a — True 
Equal a b — False 

This declaration introduces the type function Equal, gives its kind 
and, in the where clause, specifies all its equations. The first equa- 
tion has a non-linear pattern, in which a is repeated, and it overlaps 
with the second equation. If the domain were finite we could avoid 
both features by writing out all the equations exhaustively, but new 
types can be introduced at any time, so we cannot do that here. 
The issue becomes even clearer when we use kind polymorphism 
(Yorgey et al. 2012), thus: 

type family Equal (a :: k) (b :: k) :: Bool where 
Equal a a — True 
Equal a b — False 

For example, (Equal Maybe List) should evaluate to False. It may 
seem unusual to define a function to compute equality even over 
types of function kind (*—>•*). After all, there is no construct that 
can compare functions at the term level. 

At the type level, however, the type checker decides equality 
at function kinds all the time! In the world of Haskell types there 
exist no anonymous type-level functions, nor can type families 
appear partially applied, so this equality test — which checks for 
definitional equality, in type theory jargon — is straightforward. All 
Equal does is reify the (non-extensional) equality test of the type 
checker. 

In fact, Haskell programmers are used to this kind of equality 
matching on types; for example, even in Haskell 98 one can write 

instance Num a => Num (T a a) where ... 

Because the type inference engine already supports decidable 
equality, it is very straightforward to implement non-linear pat- 
terns for type functions as well as type classes. Non-linear patterns 
are convenient for the programmer, expected by Haskell users, and 
add useful expressiveness. They do make the metatheory much 
harder, as we shall see, but that is a problem that has to be solved 
only once. 

2.3 Type structure matching 

In our experience, most cases where closed type families with over- 
lapping equations are useful involve a variation on type equality. 
However, sometimes we would like to determine whether a type 
matches a specific top-level structure. 

For example, we might want to look at a function type of the 
form Int — > (Bool — > Char) — > Int — > Bool and determine that 
this is a function of three arguments. 
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data Nat = Zero \ Succ Nat 

type family CountArgs (f :: *) :: Nat where 

CountArgs (a — > b) — Succ (CountArgs b) 
CountArgs result — Zero 

Because the equations are tried in order, any function type will 
trigger the first equation and any ground non-function type (that 
is, a type that is not a type variable or an arrow type) will trigger 
the second. Thus, the type family effectively counts the number of 
parameters a function requires. 

When might this be useful? We have used this type family to 
write a variable-arity zipWith function that infers the correct ar- 
ity, assuming that the result type is not a function type. Other 
approaches that we are aware of (Fridlender and Indrika 2000; 
McBride 2002; Weirich and Casinghino 2010) require some encod- 
ing of the desired arity to be passed explicitly. A full presentation of 
the variable-arity zipWith is presented in Appendix B. To achieve 
the same functionality in a typical dependently typed language like 
Agda or Coq, we must pattern-match over some inductive universe 
of codes that can be interpreted into types. 



2.4 Observing inequality 

Type families such as Equal allow programmers to observe when 
types do not match. In other words, Equal Int Bool automatically 
reduces to False, via the second equation. With open type families, 
we could only add a. finite number of reductions of un-equal types 
to False. 

However, the ability to observe inequality is extremely use- 
ful for expressing failure in compile-time search algorithms. This 
search could be a simple linear search, such as finding an element 
in a list. Such search underlies the HList library and its encod- 
ing of heterogeneous lists and extensible records (Kiselyov et al. 
2004). It also supports Swierstra's solution to the expression prob- 
lem via extensible datatypes (Swierstra 2008). Both of these pro- 
posals use the extension -XOverlappinglnstances to implement 
a compile-time equality function. 3 

Type families can directly encode more sophisticated search al- 
gorithms than linear list searching, including those requiring back- 
tracking, simply by writing a functional program. For example, the 
following closed type family determines whether a given element 
is present in a tree. 

data Tree a = Leaf a \ Branch (Tree a) (Tree a) 

type family TMember (e :: k) (set :: Tree k) :: Bool where 

TMember e (Leaf x) — Equal e x 

TMember e (Branch left right) — 

Or ( TMember e left) ( TMember e right) 

Implementing this search using overlapping type classes, which 
do not support backtracking, requires an intricate encoding with 
explicit stack manipulation. 



2.5 Summary 

Type-level computation is a powerful idea: it allows a programmer 
to express application-specific compile-time reasoning in the type 
system. Closed type families fill in a missing piece in the design 
space, making type families more expressive, convenient, and more 
uniform with term-level functional programming. 



r, a Types 

p Type patterns (no type families) 
F Type families 

Q Substitutions from type variables to types 
Figure 1. Grammar of Haskell metavariables 



3. Simplifying closed family applications 

We have shown in the previous sections how type family reduc- 
tion can be used to equate types. For example, a function requir- 
ing an argument of type T True can take an argument of type 
T (And True True), because the latter reduces to the former. 

Because the definition of type equality is determined by type 
family reduction, the static semantics must precisely define what 
reductions are allowed to occur. That definition turns out to be 
quite subtle, so this section develops an increasingly refined notion 
of type family reduction, motivated by a series of examples. The 
presentation gives a number of definitions, using the vocabulary 
of Figure 1, but we eschew full formality until Section 4. We use 
the term "target" to designate the type-function application that 
we are trying to simplify. We say that a type n "simplifies" or 
"reduces " to another type T2 if we can rewrite the n to T2 using a 
(potentially empty) sequence of left-to-right applications of type 
family equations. We also use the notation n ~» T2 to denote 
exactly one application of a type family equation and n T2 to 
denote an arbitrary number of reductions. Type equality is defined 
to be roughly the reflexive, symmetric, transitive, congruent closure 
of type reduction; details are in Section 4.3. 

We frequently refer to the example in the introduction, repeated 
below, with the variables renamed to aid in understanding: 

type family Equal (a :: k) (b :: k) :: Bool where 
Equal a a = True — Eqn (A) 
Equal b c = False — Eqn (B) 

3.1 No functions on the LHS 

If we wish to simplify Equal Int Int, equation (A) of the definition 
matches, so we can safely "fire" the equation (A) to simplify the 
application to True. 

Even here we must take a little care. What happens if try this? 

type family F (a :: Bool) where 
F False = False 

F True — True 

F (Equal x y) = True 

Then F (Equal Int Bool) superficially appears to match only the 
third equation. But of course, if we simplify the argument of F 
in the target, it would become F False, which matches the first 
equation. 

The solution here is quite standard: in type family definitions 
(both open and closed) we do not allow functions in the argument 
types on the LHS. In terms of Figure 1, the LHS of a function 
axiom must be a pattern p. This is directly analogous to allowing 
only constructor patterns in term-level function definitions, and is 
already required for Haskell's existing open type families. 

We then propose the following first attempt at a reduction strat- 
egy: 



3 This extension allows class instances, but not type family instances, to 
overlap. If the type inference engine chooses the wrong class instance, a 
program may have incoherent behavior, but it is believed that type safety is 
not compromised. See Morris and Jones (2010) for relevant discussion. 
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Candidate Rule 1 (Closed type family simplification). An equa- 
tion for a closed type family F can be used to simplify a target 
(Ft) if (a) the target matches the LHS of the equation, and (b) no 
LHS of an earlier equation for F matches the target. 

The formal definition of matching follows: 

Definition 1 (Matching). A pattern p matches a type r, written 
match(p, t), when there is a well-kinded substitution such that 
S7(p) = T. The domain of ft must be a subset of the set of free 
variables of the pattern p. 

3.2 Avoiding premature matches with apartness 

Suppose we want to simplify Equal Bool d. Equation (A) above 
fails to match, but (B) matches with a substitution fi = [t 4 
Bool, c h-> d]. But it would be a mistake to simplify Equal Bool d 
to False. Consider the following code: 

type family Funlf (b :: Bool) :: * where 
Funlf True = Int — > Int 
Funlf False = () 

bad :: d -> Funlf (Equal Bool d) 

bad _ = () 

segFault :: Int 
segFault = bad True 5 

If we do simplify the type Equal Bool d to False then we can 
show that bad is well typed, since Funlf False is (). But then 
segFault calls bad with d instantiated to Bool. So segFault ex- 
pects bad True to return a result of type Funlf (Equal Bool Bool), 
which reduces to Int — > Int, so the call in segFault type-checks 
too. Result: we apply () as a function to 5, and crash. 

The error, of course, is that we wrongly simplified the type 
(Equal Bool d) to False; wrongly because the choice of which 
equation to match depends on how d is instantiated. While the 
target (Equal Bool d) does not match the earlier equation, there 
is a substitution for d that causes it to match the earlier equation. 
Our Candidate Rule 1 is insufficient to ensure type soundness. We 
need a stronger notion of apartness between a (target) type and a 
pattern, which we write as apart(p, r) in what follows. 

Candidate Rule 2 (Closed type family simplification). An equa- 
tion for a closed type family F can be used to simplify a target 
(F t) if (a) the target matches the LHS of the equation, and (b) 
every LHS p of an earlier equation for F is apart from the target; 
that is, apart(p,r). 

As a notational convention, apart(p~, f) considers the lists p and 
t as tuples of types; the apartness check does not go element- 
by-element. We similarly treat uses of match and unify (defined 
shortly) when applied to lists. 

To rule out our counterexample to type soundness, apartness 
must at the very least satisfy the following property: 

Property 2 (Apartness through substitution). If apart(p, r) then 
there exists no SI such that match(p, fi(r)). 

An appealing implementation of apart(p, r) that satisfies Prop- 
erty 2 is to check that the target r and the pattern p are not unifiable, 
under the following definition: 

Definition 3 (Unification). A type n unifies with a type T2 when 
there is a well-kinded substitution Q, such that O(ri) = 0(t2). 
We write unify(ri, r 2 ) = Q, for the most general such unifier if it 
exists* 



4 For instance, the implementation of unify can be the standard first-order 
unification algorithm of Robinson. 



However this test is not sufficient for type soundness. Consider 
the type Equal Int (G Bool), where G is a type family. This type 
does not match equation (A), nor does it unify with (A), but it does 
match (B). So according to our rule, we can use (B) to simplify 
Equal Int (G Bool) to False. But, if G were a type function with 
equation 

type instance G Bool — Int 

then we could use this equation to rewrite the type to Equal Int Int, 
which patently does match (A) and simplifies to True ! 

In our check of previous equations of a closed family, we wish 
to ensure that no previous equation can ever apply to a given ap- 
plication. Simply checking for unification of a previous pattern and 
the target is not enough. To rule out this counterexample we need 
yet another property from the apart(p, r) check, which ensures that 
the target cannot match a pattern of an earlier equation through ar- 
bitrary reduction too. 

Property 4 (Apartness through reduction). If apart(p, t), then for 
any t' such that r t': ^match(p, r'). 

3.3 A definition of apartness 

We have so far sketched necessary properties that the apartness 
check must satisfy — otherwise, our type system surely is not sound. 
We have also described why a simple unification-based test does 
not meet these conditions, but we have not yet given a concrete 
definition of this check. 

Note that we cannot use Property 4 to define apart(p, r) be- 
cause it would not be well founded. We need apart(p, r) to de- 
fine how type families should reduce, but Property 4 itself refers to 
type family reduction. Furthermore, even if this were acceptable, 
it seems hard to implement. We have to ensure that, for any sub- 
stitution, no reducts of a target can possibly match a pattern; there 
can be exponentially many reducts in the size of the type and the 
substitution. 

Hence we seek a conservative but cheap test. Let us consider 
again why unification is not sufficient. In the example from the 
previous section, we showed that type Equal Int (G Bool) does 
not match equation (A), nor does it unify with (A). However, 
Equal Int (G Bool) can simplify to Equal Int Int and now 
equation (A) does match the reduct. 

To take the behavior of type families into account, we first 
flatten any type family applications in the arguments of the target 
(i.e., the types r in a target Ft) to fresh variables. Only then do 
we check that the new target is not unifiable with the pattern. This 
captures the notion that a type family can potentially reduce to any 
type — anything more refined would require advance knowledge of 
all type families, impossible in a modular system. In our example, 
we must check apart((a, a), (Int, G Bool)) when trying to use the 
second equation of Equal to simplify Equal Int (G Bool). We 
first flatten (Int, G Bool) into (lnt,x) (for some fresh variable x). 
Then we check whether (a, a) cannot be unified with (Int, x). We 
quickly discover that these types can be unified. Thus, (a, a) and 
(Int, G Bool) are not apart and simplifying Equal Int (G Bool) 
to False is prohibited. 

What if two type family applications in the target type are 
syntactically identical? Consider the type family F below: 

type family Fab where 

F Int Bool = Char 
F a a = Bool 

Should the type F (G Int) (G Int) be apart from the left-hand- 
side F Int Booll If we flatten to two distinct type variables then 
it is not apart; if we flatten using a common type variable then it 
becomes apart. How can we choose if flattening should preserve 
sharing or not? Let us consider the type F b b, which matches 
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the second equation. It is definitely apart from F Int Bool and 
can indeed be simplified by the second equation. What happens, 
though, if we substitute G Int for b in F b bl If flattening did not 
take sharing into account, (G Int, G Int) would not be apart from 
(Int, Bool), and F (G Int) (G Int) wouldn't reduce. Hence, the 
ability to simplify would not be stable under substitution. This, in 
turn, threatens the preservation theorem. 

Thus, we must identify repeated type family applications and 
flatten these to the same variable. In this way, F (G Int) (G Int) 
is flattened to F x x (never F x y), will be apart from the first 
equation, and will be able to simplify to Bool, as desired. 

With these considerations in mind, we can now give our imple- 
mentation of the apartness check: 

Definition 5 (Flattening). To flatten a type t into t', written r' = 
flatten (r), process the type r in a top-down fashion, replacing 
every type family application with a type variable. Two or more 
syntactically identical type family applications are flattened to the 
same variable; distinct type family applications are flattened to 
distinct fresh variables. 

Definition 6 (Apartness). To test for apart(p, r), letr' = flatten(r) 
and check unify(p, r'). If this unification fails, then p and t are 
apart. More succinctly: apart(p, t) = ^unify(p, flatten(r)). 

We can show that this definition does indeed satisfy the identi- 
fied necessary properties from Section 3.2. In Section 5.1 we will 
also identify the sufficient conditions for type soundness for any 
possible type-safe implementation of apartness, show that these 
conditions imply the properties identified in the previous section 
(a useful sanity check!) and prove that the definition of apartness 
that we just proposed meets these sufficient conditions. 

3.4 Allowing more reductions with compatibility 

Checking for apartness in previous equations might be unneces- 
sarily restrictive. Consider this code, which uses the function And 
from Section 2.1: 

f ::T a^T b -> T (And a b) 
tt v.T True 

g :: T a -> T a 
g x — f x tt 

Will the definition of g type-check? Alas no: the call (fx tt) 
returns a result of type T (And a True), and that matches neither 
of the equations for And. Perhaps we can fix this by adding an 
equation to the definition of And, thus: 

type family And (a :: Bool) (b :: Bool) :: Bool where 
And True True = True — (1) 
And a True = a - (2) 
And a b = False - (3) 

But that does not work either: the target (And a True) matches (2) 
but is not apart from (1), so (2) cannot fire. And yet we would like 
to be able to simplify (And a True) to a, as Eqn (2) suggests. Why 
should this be sound? Because anything that matches both (1) and 
(2) will reduce to True using either equation. We say that the two 
equations coincide on these arguments. When such a coincidence 
happens, the apartness check is not needed. 

We can easily formalize this intuition. Let us say that two 
equations are compatible when any type that matches both left- 
hand sides would be rewritten by both equations to the same result, 
eliminating non-convergent critical pairs in the induced rewriting 
system: 

Definition 7 (Compatibility). Two type-family equations p and 
q are compatible iff Q,\(lhs p ) = Q,2(lhs q ) implies Qi(rhs p ) = 
Q 2 (rhs q ). 



For example, (1) and (2) are compatible because a type, such as 
And True True, would be rewritten by both to the same type, 
namely True. It is easy to test for compatibility: 

Definition 8 (Compatibility implementation). The test for compat- 
ibility, written compat(p, q), checks that unify (Ihs p , lhs q ) = im- 
plies Q.(rhs p ) — Q(rhsg). If unify (lhs p ,lhs q ) fails, compat(p, q) 
holds vacuously. 

The proof that compat(p, q) implies that p and q are compatible 
appears in Appendix G and is straightforward. We can now state 
our final simplification rule for closed type families: 

Rule 9 (Closed type family simplification). An equation q of a 
closed type family can be used to simplify a target application F r 
if the following conditions hold: 

1. The target f matches the type pattern lhs q . 

2. For each earlier equation p, either compat(p, q) or 
apart(lhs p ,r). 

For example, we can fire equation (2) on a target that is not apart 
from (1), because (1) and (2) are compatible. We show that Rule 9 
is sufficient for establishing type soundness in Section 5. 

Through this use of compatibility, we allow for a limited form 
of theorem proving within a closed type family definition. The fact 
that equation (2) is compatible with (1) essentially means that the 
rewrite rule for (2) is admissible given that for (1). By being able 
to write such equations in the closed type family definition, we can 
expand Haskell's definitional equality to relate more types. 

3.5 Optimized matching 

In our original Candidate Rule 2 above, when simplifying a target 
Ft with an equation q, we are obliged to check apart(lhs p , r), 
for every earlier equation p. But much of this checking is wasted 
duplication. For example, consider 

type family F a where 

F Int = Char - (1) 
F Bool = Bool - (2) 
Fx = Int - (3) 

If a target matches (2) there is really no point in checking its 
apartness from (1), because anything that matches (2) will be apart 
from (1). We need only check that the target is apart from any 
preceding equations that could possibly match the same target. 

Happily, this intuition is already embodied in our new simplifi- 
cation Rule 9. This rule checks compat(p, q) V apart(lhs p , r) for 
each preceding equation p. But we can precompute compat(p, q) 
(since it is independent of the target), and in the simplification rule 
we need check apartness only for the pre-computed list of earlier 
incompatible equations. In our example, equations (1) and (2) are 
vacuously compatible, since their left-hand sides do not unify, and 
hence no type can match both. Thus, there is no need to check for 
apartness from (1) of a target matching (2). 

3.6 Compatibility for open families 

As discussed in the introduction, type instance declarations for 
open type families must not overlap. With our definition of com- 
patibility, however, we can treat open and closed families more 
uniformly by insisting that any two instances of the same open type 
family are compatible: 

Definition 10 (Open type family overlap check). Every pair 
of equations p and q for an open type family F must satisfy 
compat(p, q). 

Notice that this definition also allows for coincident right-hand 
sides (as in the case for closed type families, Section 3.4). For 
example, these declarations are legal: 
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type family Coincide a b 

type instance Coincide Int b = Int 

type instance Coincide a Bool = a 

These equations overlap, but in the region of overlap they always 
produce the same result, and so they should be allowed. (GHC 
already allowed this prior to our extensions.) 

3.7 Type inference for closed type families 

Given the difficulty of type inference for open type families (Chak- 
ravarty et al. 2005; Schrijvers et al. 2008), how do we deal with 
closed ones? Thankfully, this turns out to be remarkably easy: we 
simply use Rule 9 to simplify closed families in exactly the same 
stage of type inference that we would simplify an open one. The 
implementation in GHC is accordingly quite straightforward. 

Despite the ease of implementation, there are perhaps complex 
new possibilities opened by the use of closed families — these are 
explored in Section 7.6. 

4. System \xFC: formalizing the problem 

Thus far we have argued informally. In this section we formalize 
our design and show that it satisfies the usual desirable properties 
of type preservation and progress, assuming termination of type 
family reduction. It is too hard to formulate these proofs for all 
of Haskell, so instead we formalize uFC, a small, explicitly-typed 
lambda calculus. This is more than a theoretical exercise: GHC 
really does elaborate all of Haskell into System FC (Sulzmann et al. 
2007a; Weirich et al. 2013), of which uFC is a large subset that 
omits some details of FC — such as kind polymorphism (Yorgey 
et al. 2012) — that are irrelevant here. 

4.1 System uFC 

System uFC is an extension of System F, including kinds and 
explicit equality coercions. Its syntax is presented in Figure 2. This 
syntax is very similar to recent treatments of System FC (Weirich 
et al. 2013). We omit from the presentation the choice of ground 
types and their constructors and destructors, as they are irrelevant 
for our purposes. 

There are a few points to note about type families, all visible in 
Figure 2. A type family has a particular arity, and always appears 
saturated in types. That explains the first-order notation F(k):k! in 
ground contexts E, and F(r) in types. 

A closed type family appears in uFC as a kind signature 
F(k):k', and a single axiom C:\E', both in the top-level ground 
context E. The "type" \& of the axiom is a list of equations, each 
of form [oTk]. F(t) ~ a, just as we have seen before except that 
the quantification is explicit. For example, the axiom for Equal 
(restricted for simplicity to kind *) looks like this: 

axiom Eq : [a:*]. (Equal a a) ~ True ; 

[a:*, /3:*\. (Equal a (3) ~ False 

Although our notation for lists does not make it apparent, we 
restrict the form of the equations to require that F refers to only 
one type family — that is, there are no independent Fi. We use 
subscripts on metavariables to denote which equation they refer to, 
and we refer to the types ~pi as the type patterns of the i'th equation. 
We assume that the variables a bound in each equation are distinct 
from the variables bound in other equations. 

An open type family appears as a kind signature and zero or 
more separate axioms, each with one equation. 

4.2 Static semantics 

Typing in uFC is given by the judgments in Figure 3. Most of the 
rules are uninteresting and are thus presented in Appendix C. The 
typing rules for expressions are entirely straightforward. The only 



Expressions: 



::= x I \x\T.e I ei e2 I Ka:n.e I er 



Types: 

r, a, 
ip,v 



e > 7 



a | n 

F(r) 
H 



Cast 

Constructors and destruc- 
tors of datatypes 

t-2 | Vo:k.t 

Application 
Saturated type family 
Datatype, such as Int 



p denotes a type pattern (with no type families) 

k ::= * | Ki — > ft 2 Kinds 

Propositions: 



$ ::= 
* ::= 

Coercions: 

7,7? ::= 



T\ ~ r 2 Equality propositions 
[oT7t]. F(p) ~ a Axiom equations 

$ List of axiom eqns. (axiom types) 

7i ->• 72 | Vq:k.7 | 71 72 | ^(7) 

(r) Reflexivity 

sym 7 Symmetry 

71 3 72 Transitivity 

left 7 Left decomposition 

right 7 Right decomposition 

C[i] t Axiom application 



Contexts: 
Ground: 
Variables: 
Combined: 



E 
A 

r 



Substitutions: f2 



= ■ j E, H:K -> * j E, F(k):k' | E, C:* 
= ■ I A. x:t I A, a:K 
= E;A 



Figure 2. The grammar of System uFC 



tm e : t Expression typing 



r hty t : k 

r h co 7 : <t> 

l~gnd ^ 

E h var A 
kt x r 



Type kinding 
Coercion typing 
Ground context validity 
Variables context validity 
Context validity 



Figure 3. Typing judgments for System uFC 



noteworthy rule is the one for casting, which gives the raison d'etre 
for coercions: 



T ko 7 : Ti ~ T2 r htm e : n 



TM.CAST 



T ht m e t> 7 : t 2 

Here, we see that a cast by a coercion changes the type of an ex- 
pression. This is what we mean by saying that a coercion witnesses 
the equality of two types — if there is a coercion between n and T2, 
then any expression of type n can be cast into one of type T2. 

The rules for deriving the kind of a type are straightforward and 
are omitted from this presentation. 

4.3 Coercions and axiom application 

Coercions are less familiar, so we present the coercion typing rules 
in full, in Figure 4. The first four rules say that equality is congru- 
ent — that is, types can be considered equal when they are formed of 
components that are considered equal. The following three rules as- 
sert that coercibility is a proper equivalence relation. The Co_LEFT 
and Co_RlGHT rules assert that we can decompose complex equal- 
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Coercion typing 



r \- co 71 : n ~ t[ T ho 72 : T"2 ~ T 2 
r hty Ti -¥ t 2 : * 

r h co 71 -> 72 : (ti -> T 2 ) ~ (r{ -> t£) 

r,Q:K hc 0 7 : Ti ~ T2 T ht y VarK.Ti : * 
r hjc Va:K.7 : (Va:/t.Ti) ~ (Vq:k.T2) 

r hjo 71 : r i ~ fi T hj 0 72 : t 2 ~ a 2 

T ht y Tl T 2 : K 

r hj 0 71 72 : (ti r 2 ) ~ (cri a 2 ) 



Co_Arrow 



CO_FORALL 



Co_App 



r hio 7 : r i ~ r 2 

r hty : k 



Co_Refl 



Co_Sym 



T h co F(7) : F(tT) ~ F(T2-) 

r h(y r : k 
f h co (t> : r ~ r 

T hj 0 7 : ri ~ r 2 
T h co sym 7 : t 2 ~ Ti 

r hj 0 71 : r i ~ r 2 r hjo 72 : T2 ~ T 3 
r h- co 71 5 72 : Ti ~ t 3 

r l-jo 7 : Ti t 2 ~ ai a 2 
r hjy Ti : K r hty ai : K 

T hjo left 7 : Ti ~ <Ti 

r h co 7 : Tl t 2 ~ cri a 2 
r hjy T2 : k r hty (72 : K 
r h co right 7 : t 2 ~ (7 2 

C:* G S 



Co.TyFam 



Co.Trans 



CoXeft 



CO.RlGHT 



[a:n]. F(p) ~ w 
hstx E; A 



E; A Ky t : Ki 
Vj < i, no_conflict(\E', t, t, j) 



Co_AxiOM 



E; A h co C[i] T : F{ Pl [r/a t ]) ~ ^[t/^] 



no_conflict(v|/, i, r, j) Check for equation conflicts 



* = ~ w apart(pj, p»[ r /a»]) 



no_conflict(\l/, j, r,j 

compat(^M,^|j]) 
no_conflict(\[', i,T,j) 



NC_APART 



NCXOMPATIBLE 



compat($i , <1>2) Equation compatibility 



$1 = [ai:«i]. F(pl) ~ wi 

$2 = [02TK2]. F(p2) ~ 1)2 

unify(7JT,p2) = 
a(wi) = fi(u 2 ) 

compat(<E>i, $2) 

$1 = [SI7KT]. F(pl) ~ vi 
$2 = [Q2:«2]. -F(P2) ~ v 2 
unify(pT, ~p2) fails 

compat($i, $2) 



Compat .Coincident 



COMPAT_DlSTINCT 



Figure 4. Coercion formation rules 



ities to simpler ones. These formation rules are incomplete with 
respect to some unspecified notion of semantic equality — that is, 
we can imagine writing down two types that we "know" are equal, 
but for which no coercion is derivable. For example, there is no 
way to use induction over a data structure to prove equality. How- 
ever, recall that these coercions must all be inferred from a source 
program, and it is unclear how we would reliably infer inductive 
coercions. 

The last rule of coercion formation, Co_AxiOM, is the one 
that we are most interested in. The coercion C[i] f witnesses the 
equality obtained by instantiating the i'th equation of axiom C with 
the types t. For example, 

axiomEq[0] Int : Equal Int Int ~ True 

This says that if we pick the first equation of axiomEq (we in- 
dex from 0), and instantiate it at Int, we have a witness for 
Equal Int Int ~ True. 

Notice that the coercion C[i] r specifies exactly which equation 
is picked (the i'th one); uFC is a fully-explicit language. However, 
the typing rules for uFC must reject unsound coercions like 

axiomEq[l] Int Int : Equal Int Int ~ False 

and that is expressed by rule Co_AxiOM. The premises of the rule 
check to ensure that E; A is a valid context and that all the types f 
are of appropriate kinds to be applied in the i'th equation. The last 
premise implements Rule 9 (Section 3.4), by checking no_conflict 
for each preceding equation j. The no_conflict judgment simply 
checks that either (NCXOMPATIBLE) the i'th and j'th equation 
for C are compatible, or (NC -APART) that the target is apart from 
the LHS of the j'th equation, just as in Rule 9. 

In NCXOMPATIBLE, note that the com pat judgment does not 
take the types t: compatibility is a property of equations, and is 
independent of the specific arguments at an application site. The 
two rules for com pat are exactly equivalent to Definition 8. 

These judgments refer to algorithms apart and unify. We as- 
sume a correct implementation of unify and propose sufficient 
properties of apart in Section 5.1. We then show that our chosen 
algorithm for apart (Definition 6) satisfies these properties. 

As a final note, the rules do not check the closed type family 
axioms for exhaustiveness. A type-family application that matches 
no axiom simply does not reduce. Adding an exhaustiveness check 
based on the kind of the arguments of the type family might be a 
useful, but orthogonal, feature. 

5. Metatheory 

A summary of the structure of the type safety proof, highlighting 
the parts that are considered in this paper, is in Figure 5. Our 
main goals are to prove (i) the substitution lemma of types into 
coercions (Section 5.2), and (ii) a consistency property that ensures 
we never equate two types such as Int and Bool (Section 5.3). The 
substitution and consistency lemmas lead to the preservation and 
progress theorems respectively, which together ensure type safety. 
We omit the operational semantics of uFC as well as the other 
lemmas in the main proofs of preservation and progress, because 
these are all direct adaptations from previous work (Weirich et al. 
20 1 1 ; Sulzmann et al. 2007a). 

We stress that, as Figure 5 indicates, we have proved type safety 
only for terminating type families. What exactly does that mean? 
We formally define the rewrite relation, now written E h • ~» ■ to 
explicit mention the set of axioms, with the following rule: 

C:# G E * = [oTk]. F(p) ~ v 



hgnd E T = p i [V'/ a i]_ T ' z 

Vj < i, no_conflict(*, i, tp, j) 
EhC[f(f)] ~*C[t'] 



Red 
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Type subst. lemma Good S 



i 




Figure 5. Structure of type safety proof. The arrows represent 
implications. The nodes highlighted in gray are the parts considered 
in the present work. 



In the conclusion of this rule, C[-\ denotes a type context with 
exactly one hole. Its use in the rule means that a type family 
can simplify anywhere within a type. Note that the no_conflict 
premise of this rule is identical to that of the Co_AxiOM rule. 
By "terminating type families" we mean that the E h • ■ 
relation cannot have infinite chains. We discuss non-terminating 
type families in Section 6. 

As a notational convention, we extend the relation to lists of 
types by using E h rT ~* T2 to mean that exactly one of the types 
in ?T steps to the corresponding type in ra; in all other positions tT 
and are identical. 

5.1 Preliminaries: properties of unification and apartness 

In order to prove properties about no_conflict, we must assume the 
correctness of the unification algorithm: 

Property 11 (unify correct). If there exists a substitution such 
that fl(o) = £2(t), then unify (<j,t) succeeds. If unify (a, r) = f2 
then f2 is a most general unifier of a and f . 

In Section 3.2, we gave some necessary properties of apart, 
namely Properties 2 and 4. To prove type soundness we need suf- 
ficient properties, such as the following three. Any implementation 
of apart that has these three properties would lead to type safety. 
We prove (in Appendix F) that the given algorithm for apart (Def- 
inition 6) satisfies these properties. Due to flattening in the defini- 
tion of apart, this proof is non-trivial. As a sanity check, we also 
prove that the sufficient properties imply the necessary ones of Sec- 
tion 3.2. 

Property 12 (Apartness is stable under type substitution). // 
apart(p,r), then for all substitutions Q, apart(p, f2(r)). 

Property 13 (No unifiers for apart types), //apart (p, r), then there 
exists no substitution such that f2(p) = ^(t). 

The final property of the apartness check is the most complex. It 
ensures that, if an equation can fire for a given target and that target 
steps, then it is possible to simplify the reduct even further so that 
the same equation can fire on the final reduct. 



Property 14 (Apartness can be regained after reduction). If t = 

and E h r ~+ r', then there exists a r" such that 

1. Sh?->*r", 

2. t" = n' (p) for some ft', and 

3. for every p' such that apart(p', r): apart(p', r"). 

Here is an example of Property 14 in action. Consider the following 
type families F and G : 

type family F a where 

F (Int, Bool) = Char - (A) 
F (a, a) = Bool - (B) 
type family G x where G Int = Double 

Suppose that our target is F (G Int, G Int), and that our partic- 
ular implementation of apart allows equation (B) to fire; that is, 
apart((/nr, Bool), (G Int, G Int)). Now, suppose that instead of 
firing (B) we chose to reduce the first G Int argument to Double. 
The new target is now F (Double, G Int). Now (B) cannot fire, 
because the new target simply does not match (B) any more. Prop- 
erty 14 ensures that there exist further reductions on the new target 
that make (B) Arable again — in this case, stepping the second G Int 
to Double does the job. Conditions (2) and (3) of Property 14 for- 
malize the notion "make (B) Arable again". 

5.2 Type substitution in coercions 

System uFC enjoys a standard term substitution lemma. This 
lemma is required to prove the preservation theorem. As shown 
in Figure 5, the term substitution lemma depends on the substi- 
tution lemma for coercions. We consider only the case of interest 
here, that of substitution in the rule Co_AxiOM. 

Lemma 15 (Co_Axiom Substitution). IfE; A, /?:«, A' \- co C[i] f : 

F(pi[T/a t \) ~ v t [T/ai]andT,; A h y a : k, then E; A, A'[a//3] h cc 

C[t] WW\ ■ F{piiFfc][<T/l3\) ~ ViiFfa][v/0\. 

The proof of this lemma, presented in Appendix D, proceeds 
by case analysis on the no_conflict judgment. It requires the use 
of the (standard) type substitution lemma and Property 12, but is 
otherwise unremarkable. 

5.3 Consistency 

As discussed at the beginning of this section, to establish progress 
we must show consistency. Consistency ensures that we can never 
deduce equalities between distinct value types, denoted with £: 

£ ::= Ht | n — > T2 | Vq:k.t 

For example, Int, Bool, and V a:*. a — > a are all value types. A set 
of axioms is consistent if we cannot deduce bogus equalities like 
Int ~ Bool or Int ~ Va:ta — > a: 

Definition 16 (Consistent contexts). A ground context E is consis- 
tent if for all coercions 7 such that E; • hj 0 7 : £1 ~ £2-' 

!• if £1 = Ht[, then £2 = HT2, 

2. if£i — n — > t[, then £2 = T2 — > 12, and 

3. if^i =Va:K.Ti, then £ 2 =V/3:k.t 2 . 

How can we check whether an axiom set is consistent? It is 
extremely hard to do so in general, so instead, following previous 
work (Weirich et al. 2011), we place syntactic restrictions on the 
axioms that conservatively guarantee consistency. A set of axioms 
that pass this check are said to be Good. We then prove the 
consistency lemma: 

Lemma 17 (Consistency). If Good E, then E is consistent. 

Following previous proofs, we show that if Good E and 
E; • h; 0 7 : o\ ~ 02, then o~\ and 02 have a common reduct 
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Figure 6. Graphical representation of confluence properties. A 
solid line is a universally quantified input, and a dashed line is an 
existentially quantified output. 



in the ~~> relation. Because the simplification relation preserves 
type constructors on the heads of types, we may conclude that E is 
consistent. 

However, one of the cases in this argument is transitivity: the 
joinability relation must be transitive. That is, if n and T2 have a 
common reduct cri, and if T2 and T3 have a common reduct 02, then 
Ti and T3 must have a common reduct (they are joinable). To show 
transitivity of joinability, we must show confluence of the rewrite 
relation, in order to find the common reduct of 01 and 02 (which 
share T2 as an ancestor). 

Our approach to this problem is to show local confluence (see 
Figure 6) and then use Newman's Lemma (1942) to get full con- 
fluence. Newman's Lemma requires that the rewrite system is 
terminating — this is where the assumption of termination is used. 

The full, detailed proof appears in Appendix E. 

5.4 Good contexts 

What sort of checks should be in our syntactic conditions, Good? 
We would like Good to be a small set of common-sense conditions 
for a type reduction system, such as the following: 

Definition 18 (Good contexts). We have Good E whenever the 
following four conditions hold: 



1. For all C:^ G E: * is of the form [a:n]. F(p) ~ v where all 
of the Fi are the same type family F and all of the type patterns 
pi do not mention any type families. 

2. For all C:$ G E and equations [oan]. F(p) ~ v in the 
variables a all appear free at least once in p. 

3. For all C:^ G E: if ^ defines an axiom over a type family F 
and has multiple equations, then no other axiom C':^>' G E 
defines an axiom over F. That is, all type families with ordered 
equations are closed. 

For all Ci:$i G E and C2:$2 G E (each with only one 
equation), compat($i , $2)- That is, among open type families, 
the patterns of distinct equations do not overlap. 



4 



The clauses of the definition of Good are straightforward 
syntactic checks. In fact, these conditions are exactly what GHC 
checks for when compiling type family instances. This definition 
of Good leads to the proof of Lemma 39, as described above. 

6. Non-terminating type families 

By default GHC checks every type family for termination, to guar- 
antee that the type checker will never loop. Any such check is 
necessarily conservative; indeed, GHC rejects the TMember func- 
tion of Section 2.4 (Schrijvers et al. 2008). Although GHC's test 
could readily be improved, any conservative check limits expres- 
siveness or convenience, so GHC allows the programmer to disable 



type instance A = C A 

type instance C x — D x (C x) 

type instance D x x = Int 

(1) A~* CA~^ DA (C A) ~* D (C A) (C A) ~» Int 

(2) A~* CA~>t ym C Int 

Int and C Int have no common reduct. 
Figure 7. Counter-example to confluence 

the check. This may make the type checker loop, but it should not 
threaten soundness. 

However, the soundness result of Section 5 covers only termi- 
nating type families. Surprisingly (to us) non-termination really 
does lead to a soundness problem (Section 6.1). We propose a so- 
lution that (we believe) rules out this problem (Section 6.2), but 
explain why the main result of this paper is difficult to generalize 
to non-terminating type families, leaving an open problem for fur- 
ther work. 

6.1 The problem with infinity 

Consider this type family, adapted from Huet (1980): 

type family D x where 

D {[b],b) = Bool 
D (c, c) = Int 

We wish to simplify the target D (a, a). The type (a, a) matches 
the second pattern (c, c), but is it apart from the first pattern 
([fa], fa)? Definition 6 asserts that they are apart since they do not 
unify: unification fails with an occurs check error. Accordingly, 
Rule 9 would simplify D (a, a) to Int. But consider the following 
definitions, where type family Loop is a nullary (0-argument) type 
family: 

type family Loop 

type instance Loop = [Loop] 

If we instantiate a with Loop we get (Loop, Loop) which can sim- 
plify to ([Loop], Loop). The latter does match the pattern ([fa], fa), 
violating Property 4, a necessary condition for soundness. 

So, in a non-terminating system our apartness check is unsound. 
Concretely, using our apartness implementation from Definition 6, 
we can equate types Int and Bool, thus: 



Int 



D (Loop, Loop) ~ D ([Loop], Loop) ~ Bool 



Conclusion: we must not treat (a, a) as apart from the pattern 
([fa], fa), even though they do not unify. In some ways this is not 
so surprising. In our earlier examples, apartness was based on 
an explicit contradiction ("a Bool cannot be an Int"), but here 
unification fails only because of an occurs check. As the Loop 
example shows, allowing non-terminating type-family definitions 
amounts to introducing infinite types, and if we were to allow 
infinite types, then (a, a) does unify with ([fa], fa)! 

6.2 Fixing the problem 

The problem with the current apartness check is that finite unifica- 
tion fails too often. We need to replace the unification test in the 
definition of apartness with unification over infinite types: 

Definition 19 (Infinite unification). Two types n , T2 are infinitely 
unifiable, written unify oo (ri, r 2 ), if there exists a substitution uj 
whose range may include infinite types, such that u>{ti) = o>(t 2 ). 

For example types (a, a) and ([fa], fa) are unifiable with a sub- 
stitution a; = [a <-¥ [[[•■■]]], fa n> [[[...]]]]. Efficient algorithms 
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to decide unification over infinite types (and compute most gen- 
eral unifiers) have existed for some time and are based on well- 
established theory (Huet 1976; Courcelle 1983). See Jaffar (1984) 
for such an algorithm, and Knight (1989) for a general survey. 

We conjecture that replacing all uses of unify with unify^ 
in our definitions guarantees soundness, even in the presence of 
non-terminating family equations. Alas, this conjecture turns out 
to be very hard to prove, and touches on open problems in the 
term-rewriting literature. For example, a rewrite system that has 
(a) infinite rewrite sequences and (b) non-left-linear patterns, does 
not necessarily guarantee confluence, even if its patterns do not 
overlap. Figure 7 gives an example, from Klop (1993). 

Notice that replacing unify with unify^ may change the reduc- 
tion relation. For example, a target which is apart from a pattern 
with a unify-based apartness check may no longer be apart from the 
same pattern with the more conservative unify^-based apartness 
check. Yet, type safety (for terminating axiom sets) is not compro- 
mised since Property 1 1 carries over to unification algorithms over 
infinite types (Huet 1976). 

6.3 Ramifications for open families 

We pause briefly to consider the implications for GHC's existing 
open type families. GHC allows the following definition for an 
open type family D': 

type family D' x y 

type instance D' [b] b = Bool 

type instance D' c c = Int 

As described in Section 2, the type instance equations of an open 
type family are required to have non-overlapping left-hand sides, 
and GHC 7.6 believes that the two equations do not overlap because 
they do not unify. But, using certain flags, GHC also accepts the 
definition of Loop, and the target (D' Loop Loop) demonstrates 
that the combination is unsound precisely as described above. 5 

Happily, if the conjecture of Section 6.2 holds true, we can apply 
the same fix for open families as we did for closed families: simply 
use unify ^ instead of unify when checking for overlap. Indeed, this 
is exactly how we have corrected this oversight in GHC 7.8. 

7. Discussion and Future Work 

The study of closed type families opens up a wide array of related 
issues. This section discusses some of the more interesting points 
we came across in our work. 

7.1 Denotational techniques for consistency 

We do not have a proof of consistency for a system with non- 
terminating, non-left-linear axioms (even when using unify ^ in- 
stead of unify). We have seen that confluence is false, and hence 
cannot be used as a means to show consistency. 

A possible alternative approach to proving consistency — side- 
stepping confluence — is via a denotational semantics for types. We 
would have to show that if we can build a coercion 7 such that 
r h 7 : r ~ a, then [r] = [<r], for some interpretation of types 
into a semantic domain. The "obvious" domain for such a seman- 
tics, in the presence of non-terminating computations, is the domain 
that includes _L as well as finite and infinite trees. Typically in de- 
notational semantics, recursive type families would be interpreted 
as the limit of approximations of continuous functions. However, 
the "obvious" interpretation of type families in this simple domain 
is not monotone. Consider this type family: 

5 Akio Takano has posted an example of how this can cause a program to 
fail, at http : / /ghc .haskell . org/trac/ghc/ticket/8162. 



type family Fab where 

F x x —Int 
F [x] (Maybe x) = Char 

It is the case that (_L IZ [_L]) and (_L IZ Maybe _L), but the semantic 
interpretation of F, call it /, should satisfy /(_L,_L) = Int and 
/([_L], Maybe _L) = Char. Hence, monotonicity breaks. The lack 
of monotonicity means that limits of chains of approximations do 
not exist, and thus that interpretations of functions, such as /, are 
ill-defined. 

An alternate definition would give /(_L, _L) = _L, but then sub- 
stitutivity breaks. Indeed, the proof theory can deduce that F x x is 
equal to Int for any type x, even those that have denotation _L. 

Alternatively to these approaches, one might want to explore 
different domains to host the interpretation of types. 

7.2 Conservativity of apartness 

We note in Section 3.3 that our implementation of apartness is 
conservative. This conservativity is unavoidable — it is possible for 
open type families to have instances scattered across modules, 
and thus the apartness check cannot adequately simplify the types 
involved in every case. However, the current check considers none 
of the type family axioms available, even if one would inform the 
apartness check. For example, consider 

type family G a where 

G Int = Bool 
G [a] = Char 

and we wish to simplify target Equal Double (G b). It is clear 
that an application of G can never simplify to Double, so we could 
imagine a more refined apartness check that could reduce this target 
to False. We leave the details of such a check to future work. 

7.3 Conservativity of coincident overlap: partial knowledge 

It is worth noting that the compatibility check (Definition 8) is 
somewhat conservative. For example, take the type family 

type family Fab where 

F Bool c = Int 
F d e = e 

Consider a target F g Int. The target matches the second equation, 
but not the first. But, the simplification rule does not allow us to fire 
the second equation — the two equations are not compatible, and the 
target is not apart from the first equation. Yet it clearly would be 
safe to fire the second equation in this case, because even if g turns 
out to be Bool, the first equation would give the same result. 

It would, however, be easy to modify F to allow the desired 
simplification: just add a new second equation F a Int — Int. This 
new equation would be compatible with the first one and therefore 
would allow the simplification of F g Int. 

7.4 Conservativity of coincident overlap: requiring syntactic 
equality 

The compatibility check is conservative in a different dimension: it 
requires syntactic equality of the RHSs after substitution. Consider 
this tantalizing example: 

type family Plus a b where 

Plus Zero a = a — (A) 

Plus (Succ b) c = Succ (Plus b c) - (B) 

Plus d Zero =d - (C) 

Plus e (Succ f) = Succ (Plus e f) - (D) 

If this type family worked as one would naively expect, it would 
simplify an addition once either argument's top-level constructor 
were known. (In other dependency typed languages, definitions 
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like this are not possible and require auxiliary lemmas to reduce 
when the second argument's structure only is known.) Alas, it does 
not work as well as we would hope. The problem is that not all 
the equations are compatible. Let's look at (B) and (C). To check 
if these are compatible, we unify ((Succ b), c) with (d, Zero) to 
get [c i-> Zero, d i-> Succ b]. The right-hand sides under this 
substitution are Succ (Plus b Zero) and Succ b. However, these 
are not syntactically identical, so equations (B) and (C) are not 
compatible, and a target such as Plus g Zero is stuck. 

Why not just allow reduction in the RHSs before checking for 
compatibility? Because doing so is not obviously well-founded! 
Reducing the Succ (Plus b Zero) type that occurred during the 
compatibility check above requires knowing that equations (B) and 
(C) are compatible, which is exactly what we're trying to establish. 
So, we require syntactic equality to support compatibility, and leave 
the more general check for future work. 

7.5 Lack of inequality evidence 

One drawback of closed type families is that they sometimes do 
not compose well with generalized algebraic datatypes (GADTs). 
Consider the following sensible-looking example: 

data X a where 

XI nt ::X Int 
XBool :: X Bool 
XChar :: X Char 

type family Collapse a where 
Collapse Int = Int 
Collapse x = Char 

collapse :: X a — > X (Collapse a) 
collapse Xlnt = Xlnt 
collapse _ = XChar 

The type function Collapse takes Int to itself and every other type 
to Char. Note the type of the term-level function collapse. Its im- 
plementation is to match Xlnt — the only constructor of X param- 
eterized by Int — and return Xlnt; all other constructors become 
XChar. The structure of collapse exactly mimics that of Collapse. 
Yet, this code does not compile. 

The problem is that the type system has no evidence that, in the 
second equation for collapse, the type variable a cannot be Int. So, 
when type-checking the right-hand side XChar, it is not type-safe 
to equate Collapse a with Char. The source of this problem is that 
the type system has no notion of inequality. If the case construct 
were enhanced to track inequality evidence and axiom application 
could consider such evidence, it is conceivable that the example 
above could be made to type-check. Such a notion of inequality has 
not yet been considered in depth, and we leave it as future work. 

7.6 Type inference 

The addition of closed type families to Haskell opens up new possi- 
bilities in type inference. By definition, the full behavior of a closed 
type family is known all at once. This closed-world assumption al- 
lows the type inference engine to perform more improvement on 
types than would otherwise be possible. Consider the following 
type family: 

type family Inj a where 

Inj Int — Bool 
Inj Bool — Char 
Inj Char — Double 

Type inference can discover in this case that Inj is indeed an 
injective type function. When trying to solve a constraint of the 
form Inj Int ~ Inj q the type inference engine can deduce that 
q must be equal to Int for the constraint to have a solution. By 



contrast, if Inj were not identified as injective, we would be left 
with an unsolved constraint as in principle there could be multiple 
other types for q that could satisfy Inj Int ~ Inj q. 

Along similar lines, we can imagine improving the connection 
between Equal and ( ~ ). Currently, if a proof a ~ b is available, 
type inference will replace all occurrences of a with b, after which 
Equal a b will reduce to True. However, the other direction does 
not work: if the inference engine knows Equal a b ~ True, it will 
not deduce a ~ b. Given the closed definition of Equal, though, 
it seems possible to enhance the inference engine to be able to go 
both ways. 

These deductions are not currently implemented, but remain as 
compelling future work. 

8. Related work 

8.1 Previous work on System FC 

The proof of type soundness presented in this paper depends heav- 
ily on previous work for System FC, first presented by Sulzmann 
et al. (2007a). That work proves consistency only for terminating 
type families, as we do here. 

In a non-terminating system, local confluence does not imply 
confluence. Therefore, previous work (Weirich et al. 2011) showed 
confluence of the rewrite system induced by the (potentially non- 
terminating) axiom set by establishing a local diamond property 
(see Figure 6). However, the proof took a shortcut: the require- 
ments for good contexts effectively limited all axioms to be left- 
linear. The local diamond proof relies on the fact that, in a system 
with linear patterns, matching is preserved under reduction. For in- 
stance, consider these axioms: 

type instance F a b = H a 
type instance G Int — Bool 

The type F (G Int) (G Int) matches the equation for F and can 
potentially simplify to F (G Int) Bool or to F Bool (G Int) or 
even to F Bool Bool. But, in all cases the reduct also matches 
the very same pattern for F, allowing local diamond property to be 
true. 6 

What is necessary to support a local diamond property in a 
system with closed type families, still restricted to linear patterns? 
We need this property: If F f can reduce by some equation q, and 
T ~-> t' , then F r' can reduce by that same equation q. With only 
open families, this property means that matching must be preserved 
by reduction. With closed families, however, both matching and 
apartness must be preserved by reduction. Consider the definition 
for F below (where H is some other type family): 

type family F' a b where 

F' Int Bool = Char 
Fab = H a 

We know that F' (G Int) (G Int) matches the second equation 
and is apart (Definition 6) from the first equation. The reduct 
F' (G Int) Bool also matches the second equation but is not apart 
from the first equation. Hence, F' (G Int) Bool cannot simplify 
by either equation for F', and the local diamond property does not 
hold. Put simply, our apartness implementation is not preserved by 
reduction. 

In a terminating system, we are able to get away with the weaker 
Property 14 for apart (where apartness is not directly preserved 
under reduction), which our implementation does satisfy. We have 
designed an implementation of apart which is provably stable 
under reduction, but it is more conservative and less intuitive for 
programmers. Given that this alternative definition of apart brought 



6 Actually, under parallel reduction; see (Weirich et al. 201 1). 
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a proof of type safety only for potentially non-terminating but 
linear patterns (prohibiting our canonical example Equal), and 
that it often led to stuck targets where a reduction naively seemed 
possible, we have dismissed it as being impractical. We thus seek 
out a proof of type safety in the presence of non-terminating, non- 
left-linear axiom sets. 

8.2 Type families vs. functional dependencies 

Functional dependencies (Jones 2000) (further formalized by Sulz- 
mann et al. (2007b)) allow a programmer to specify a dependency 
between two or more parameters of a type class. For example, Kise- 
lyov et al. (2004) use this class for their type-level equality func- 
tion: 7 

class HEq x y (b :: Bool) x y — > b 

instance HEq x x True 

instance (b ~ False) => HEq x y b 

The annotation x y — > b in the class header declares a functional 
dependency from x and y to b. In other words, given x and y, we 
can always find b. 

Functional dependencies have no analogue in GHC's internal 
language, System FC; indeed they predate it. Rather, functional de- 
pendencies simply add extra unification constraints that guide type 
inference. This can lead to very compact and convenient code, es- 
pecially when there are multiple class parameters and bi-directional 
functional dependencies. However, functional dependencies do not 
generate coercions witnessing the equality between two types. 
Hence they interact poorly with GADTs and, more generally, with 
local type equalities. For example, consider the following: 

class Same a b \ a — > b 
instance Same Int Int 

data T a where 

Tl :: T Int 
T2 v.T a 
data S a where 

MkS :: Same a b => b — > S a 

f :: T a -> S a -> Int 
f Tl (MkS b) = b 
f T2 s =3 

In the Tl branch of f we know that a is Int, and hence (via the 
functional dependency and the Same Int Int instance declaration) 
the existentially-quantified b must also be Int, and the definition 
should type-check. But GHC rejects f , because it cannot produce a 
well-typed FC term equivalent to it. Could we fix this, by producing 
evidence in System FC for functional dependencies? Yes; indeed, 
one can regard functional dependencies as a convenient syntactic 
sugar for a program using type families. For example we could 
translate the example like this: 

class F a ~ b => Same a b where 

type F a 
instance Same Int Int where 

type F Int = Int 

Now the (unchanged) definition of f type-checks. 

A stylistic difference is that functional dependencies and type 
classes encourage logic programming in the type system, whereas 
type families encourage functional programming. 



'Available from http://okmij.Org/ftp/Haskell/types.html# 
HList. 



8.3 Controlling overlap 

Morris and Jones (2010) introduce instance chains, which obviate 
the need for overlapping instances by introducing a syntax for 
ordered overlap among instances. Their ideas are quite similar to 
the ones we present here, with a careful check to make sure that 
one instance is impossible before moving onto the next. However, 
the proof burden for their work is lower than ours — a flaw in 
instance selection may lead to incoherent behavior (e.g., different 
instances selected for the same code in different modules), but 
it cannot violate type safety. This is because class instances are 
compiled solely into term-level constructs (dictionaries), not type- 
level constructs. In particular, no equalities between different types 
are created as part of instance compilation. 

8.4 Full-spectrum dependently typed languages 

Type families resemble the type-level computation supported by 
dependently typed languages. Languages such as Coq (Coq devel- 
opment team 2004) and Agda (Norell 2007) allow ordinary func- 
tions to return types. As in Haskell, type equality in these languages 
is defined to include /3-reduction of function application and t- 
reduction of pattern matching. 

However, there are several significant differences between these 
type-level functions and type families. The first is that Coq and 
Agda do not allow the elimination of their equivalents of kind *. 
There is no way to write a Coq/Agda function analogous to the 
closed type family below, which returns True for function types 
and False otherwise. 

type family IsArrow (a :: *) :: Bool where 
IsArrow (a — > b) — True 
IsArrow a — False 

Instead, pattern matching is only available for inductive datatypes. 
The consistency of these languages prohibits the elimination of 
non-inductive types such as ★ (or Set, Prop, and Type). 

Furthermore, pattern matching in Coq and Agda does not sup- 
port non-linear patterns. As we discussed above, non-linear patterns 
allow computation to observe whether two types are equal. How- 
ever, the equational theory of full spectrum languages is much more 
expressive than that of Haskell. Because these languages allow un- 
saturated functions in types, it must define when two functions are 
equal. This comparison is intensional, and allowing computation 
to observe intensional equality is somewhat suspicious. However, 
in Haskell, where all type functions must always appear saturated, 
this issue does not arise. 

Due to the lack of non-linear patterns, Coq and Agda program- 
mers must define individual functions for every type that supports 
decidable equality. (Coq provides a tactic — decide equality — 
to automate this definition.) Furthermore, these definitions do not 
immediately imply that equality is reflexive; this result must be 
proved separately and manually applied. In contrast, the closed type 
family Equal a a immediately reduces to True. 

Similarly, functions in Coq and Agda do not support coincident 
overlap at definition time. Again, these identities can be proven as 
lemmas, but must be manually applied. 

8.5 Other functional programming languages 

Is our work on closed type families translatable to other func- 
tional programming languages with rich type-level programming? 
We think so. Though the presentation in this paper is tied closely 
to Haskell, we believe that the notion of apartness would be quite 
similar (if not the same) in another programming language. Ac- 
cordingly, the analysis of Section 3 would carry over without much 
change. The one caveat is that, as mentioned above, non-linear pat- 
tern matching depends on the saturation of all type-level functions. 
If this criterion is met, however, we believe that other languages 
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could adopt the surface syntax and behavior of closed type families 
as presented here without much change. 

9. Conclusions 

Closed type families improve the usability of type-level compu- 
tation, and make programming at the type level more reminis- 
cent of ordinary term-level programming. At the same time, closed 
families allow for the definition of manifestly-reflexive, decidable 
equality on types of any kind. They allow automatic reductions of 
types with free variables and allow the user to specify multiple, po- 
tentially overlapping but coherent reduction strategies (such as the 
equations for the And example). 

On the theoretical side, the question of consistency for non- 
terminating non-left-linear rewrite systems is an interesting re- 
search problem in its own right, quite independent of Haskell or 
type families, and we offer it as a challenge problem to the reader. 
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A. Description of units package 

Using closed type families, we have written a library units, 8 for 
strongly-typed dimensional analysis. For example, we want to write 
functions like this: 

curPos :: Pos — > Velocity — > Acceleration — > Time — > Pos 
curPos xo v a t = xo .+ (v .* t) .+ (0.5 *. a .* (t ." pTwo)) 

The above code works with our library and type-checks. However, 
if we were to make an expression that does not respect physical 
units (say, by forgetting the t in the v .* t), we get a type error 
at compile time. For that particular case, the error says Couldn't 
match type 'Meter' with ' Second' , rather helpfully. 

Importantly, this library is fully extensible. There are no wired- 
in units, except for Scalar. This way, users can apply the library to 
situations beyond just physics. For example, it might be sensible to 



cabal install units; you will need GHC 7.8. 
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have HPixel and VPixel units when writing a drawing program, to 
make sure that you don't ever add a height with a width. 

In order to support extensibility, new units are represented by 
new datatypes, in kind For example, here are the definitions for 
two units: 

data Meter = Meters 
instance Unit Meter where 

type BaseUnit Meter — Canonical 

data Foot — Feet 
instance Unit Foot where 

type BaseUnit Foot — Meter 

conversion Ratio _ = 0.3048 

type Pos = MkDim Meter 

It is the library's extensibility that requires closed type families. 
It needs to reason about type-level structures without being able 
to enumerate all the possibilities, and without requiring the user to 
be well-versed in type families. There are two independent ways 
that closed type families are required in the design of the library: 
manipulating dimension specifications as type-level sets (which is 
similar to the example in Section 2.4) and managing the hierarchies 
of inter-convertible units. 

Building a hierarchy of units with a distinguished root In the 
definition of Meter and Foot above, we also defined their relation- 
ship. The code says that Meter is a canonical unit — that is, it is 
not defined in terms of something else. On the other hand, Foot is 
defined in terms of Meter, so that we can write code like 

height :: Double 

height = (1.8 % Meters) # Feet 

and height will have the value 5.9055. Of course, we could convert 
feet to meters simply by reversing the statement. 

Say a library has been written on top of units that defines 
several different length measurements, such as Meters, Feet, and 
LightYears. Now, a user of that library realizes that she needs to 
define Inches. She would like to define inches in terms of Feet, 
because she knows that conversion ratio. But, she doesn't know 
which of the existing length units is the canonical one. Part of the 
design principle behind the units library is that she does not need 
to know — she can define Inches in terms of any of the available 
length units. 

With this design in hand, we still need a way to compute the 
conversion from our internal representation of a length — which 
will be in Meters, the canonical unit — to Inches. We can see that 
the declared units form a tree, rooted at Meters, and each new 
unit refers to its BaseUnit, or parent in the tree. To find the right 
conversion ratio, we simply have to walk up the tree from the 
desired unit, multiplying all of the conversion ratios together. 

But, how to implement this in Haskell? Recall that this tree 
is a tree of types, which are erased at runtime. We should use a 
class Unit that defines the conversion ratios, and we can have an 
associated type BaseUnit the defines a unit's parent in the tree. We 
introduce an empty type Canonical to serve as a canonical unit's 
(i.e., Meter's) parent, or BaseUnit. Then, we can (seemingly) 
implement the conversion ratio calculation straightforwardly: 

class (Unit (BaseUnit u)) => Unit u where 
type BaseUnit u :: * 
conversion Ratio :: u — > Double 

— ratio from u to u's parent 

canonicalConvRatio :: u — > Double 

— ratio from u to canonical unit, 

— with default implementation 
canonicalConvRatio u 



= (conversion Ratio u) * 

(canonicalConvRatio (_L :: BaseUnit u)) 

(The instance for the Canonical type breaks the recursion in 
canonicalConvRatio by overriding the default definition.) 

There is a major problem with Unit as defined here — it has 
a superclass cycle. The header states that every Unit's. BaseUnit 
must also be a Unit, which is clearly ill-founded. Yet, this idea is 
sensible, because we need to be able to call canonicalConvRatio 
on a BaseUnit. What to do? 

The full answer would take up too much space to describe (and 
is available if you download the units package), but it boils down 
to this: 

type family CheckCanonical (unit :: *) :: Bool where 
CheckCanonical Canonical = True 
CheckCanonical unit = False 

Using CheckCanonical, we can define a conditional constraint, 
essentially saying that every non-canonical unit must have a unit as 
its parent. This breaks the type-level recursion and brings us back 
onto solid footing. 

It is never wise to say that an alternate encoding is impossible 
in Haskell, but we were unable to find another one that works 
smoothly and presents a very easy interface to users. 

B. zipWith with inferred arity 

Using the CountArgs closed type family from Section 2.3, we can 
define a variable-arity zipWith function that infers the correct arity 
from its first argument. 

We first need a definition of the natural numbers. This definition 
will only be used as a promoted datafoW. 

data Nat = Zero | Succ Nat 

In our description, we will abbreviate these unary numbers with 
ordinary decimals. 

What will the type of our final zipWith be? It will first take a 
function and then several lists. The types of these lists is determined 
by the type of the function passed in. For example, suppose our 
function f has type Int — > Bool — > Double, then the type of 
zipWith should be (Int -> Bool -> Double) -> [Int] -> 
[Bool] — > [ Double ] . Thus, we wish to take the type of the function 
and apply the list type constructor [ ] to each component of it. 

Before we write the code for this operation, we pause to note 
an ambiguity in this definition. Both of the following are sensible 
concrete types for a zipWith over the function f: 

zipWith :: (/nt -> Bool -> Double) 

-> [Int] -> [Bool -> Double] 
zipWith :: (/nt -S- Bool -S- Double) 

-> [Int] -> [Bool] -> [Double] 

The first of these is essentially map; the second is the classic 
function zipWith that expects two lists. Thus, we must pass in the 
desired number of parameters to apply the list type constructor to. 
(The inferred arity comes in later.) The function to apply these list 
constructors is named Listify: 

type family Listify (n :: Nat) arrows where 
Listify Zero a =[ a ] 
Listify (Succ n) (a ->• b) = [a] -> Listify n b 

We now need to create some runtime evidence of our choice 
for the number of arguments. This will be used to control the 
runtime operation of zipWith — after all, our function must have 
both the correct behavior and the correct type. We use a GADT 
NumArgs that plays two roles: it controls the runtime behavior as 
just described, and it also is used as evidence to the type checker 
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that the number argument to Listify is appropriate. After all, we 
do not want to call Listify 2 (Int — > Bool), as that would 
be stuck. By pattern-matching on the NumArgs GADT, we get 
enough information to allow Listify to fully reduce. 



data NumArgs :: Nat — > * - 
NAZero :: 

NASucc :: NumArgs n b 



* where 

NumArgs Zero a 
• NumArgs (Succ n) (a - 



b) 



We now write the runtime workhorse listApply, with the fol- 
lowing type: 

listApply :: NumArgs n a — > [a] — > Listify n a 

The first argument is the encoding of the number of arguments 
to the function. The second argument is a list of functions to 
apply to corresponding elements of the lists passed in after the 
second argument. Why do we need a list of functions? Consider 
evaluating zip With (+) [1,2] [3, 4], where we recur not only on 
the elements in the list, but on the number of arguments. After 
processing the first list, we have to be able to apply different 
functions to each of the elements of the second list. To wit, we need 
to apply the functions [(1+), (2+)] to corresponding elements in 
the list [3, 4]. (Here, we are using Haskell's "section" notation for 
partially-applied operators.) 

Here is the definition of listApply : 

listApply NAZero fs = fs 
listApply (NASucc na) fs = 

\args — > listApply na (apply fs args) 
where apply :: [a — > b] — > [a] — ¥ [b] 

apply (f : fs) (x : xs) = (f x : apply fs xs) 
apply. _ = [] 

It first pattern-matches on its first argument. In the NAZero case, 
the list of functions passed in has 0 arguments, so we just return 
them. In the NASucc case, we process one more argument (args), 
apply the list of functions fs respectively to the elements of args, 
and then recur. Note how the GADT pattern-matching is essential 
for this to type-check — the type checker gets just enough informa- 
tion for Listify to reduce enough so that the second case can expect 
one more argument than the first case. 

Inferring arity As explained in Section 2.3, here is the closed 
type family that counts the number of arguments in a function type: 

type family CountArgs (f :: *) :: A/at where 
CountArgs (a —¥ b) — Succ (CountArgs b) 
CountArgs result = Zero 

We still need to connect this type-level function with the term- 
level GADT NumArgs. We use Haskell's method for reflecting 
type-level decisions on the term-level, type classes. The following 
definition essentially repeats the definition of NumArgs, but be- 
cause this is a definition for a class, the instance is inferred rather 
than given explicitly: 

class CNumArgs (numArgs :: Nat) (arrows :: *) where 

getNA :: NumArgs numArgs arrows 
instance CNumArgs Zero a where 

getNA = NAZero 
instance CNumArgs n b => 

CNumArgs (Succ n) (a — > b) where 

getNA = NASucc getNA 

Note that the instances do not overlap; they are distinguished by 
their first parameter. 

It is now straightforward to give the final definition of zipWith, 
using the extension -XScopedTypeVariables to give the body of 
zipWith access to the type variable f: 



zipWith :: V f. CNumArgs (CountArgs f) f 

=> f — > Listify (CountArgs f) f 
zipWith fun 

= listApply (getNA :: NumArgs (CountArgs f) f) (repeat fun) 

The standard Haskell function repeat creates an infinite list of its 
one argument. 

The following examples show that zipWith indeed infers the 
arity: 

example 1 = zipWith (A) [False, True, False] [True, True, False] 
example 2 = zipWith ((+) :: Int -> Int -»■ Int) [1, 2, 3] [4, 5, 6] 

concat :: Int — > Char — > Double — > String 
concat a b c — (show a) -+f (show b) -+f (show c) 
example.^ = zipWith concat [1,2,3] ['a', 'b', »c'] 

[3.14,2.1728,1.01001] 

In example 2 , we must specify the concrete instantiation of (+). 
In Haskell, built-in numerical operations are generalized over 
a type class Num. In this case, the operator (+) has the type 
Num a => a — > a — > a. Because it is theoretically possible 
(but deeply strange!) for a to be instantiated with a function type, 
using (+) without an explicit type will not work — there is no way 
to infer an unambiguous arity. Specifically, CountArgs gets stuck. 
CountArgs (a — > a — > a) simplifies to Succ (Succ (CountArgs a)) 
but can go no further; CountArgs a will not simplify to Zero, be- 
cause a is not apart from b — > c. 

C. Typing judgments for System uFC 

h^nd £ Ground context validity 



hgnd E H ^ E 

\~gnd E, H:k — > * 

h gnd E F#E 



Gnd.Empty 



Gnd.Ground 



hgnd X,F(k):k' 
F(k):k' g S 
S;qTk h ty p:~k C#E 
E ; ot\K hty v : k' 



Gnd.TyFam 



r|nd 



E h var A 



hgnd E, C:[oTk]. F(p) ~ v 
Variables context validity 



GND.AXIOM 



r~gnd 



Eh ua 



E;Ah- tv r: 



- Var.Empty 



h-ctxT 



E h^a,- A, X-.T 

E h var A a # A 
E h; ar A, a:K 
Context validity 

E h var A 



Var.TermVar 



Var.TypeVar 



h-ctx E; A 
Expression typing 

x:t G A h- c tx E; A 
E; A Km x : t 
T, x:ti htm e : r 2 

T ht m \x\Tl.e : Tl — > T2 



Ctx_Valid 



Tm_Var 



Tm_Abs 
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r ht m ei : n 



T2 



T htm e2 : Ti 



r htm ei e2 : T2 
T, q:k Km e : r 
r htm Aa:K.e : Vfcc.T 
r Km e : Va:K.T2 r h y Ti : K 



T Km e n : T2 [n / a] 

r h co 7 : ri ~ r 2 r h m e : Ti 
T htm e > 7 : r 2 
Type kinding 

q:k G A h- c tx E; A 



Tm_App 
Tm.TyAbs 

Tm_TyApp 



TmXast 



r hty r : K 



E; A ht y a : k 
F(k):k' € E h- c tx E; A 



Ty_Var 



S; A ht v r 



E; A hy F(r) : k' 

H:k-^* G E h ctx E; A 
E; A h ty H : k -> * 

r hy Tl : * T hy T2 : ★ 

r h ty n -> r 2 : * 

r, q:k hy T : * 
T hy Vkk.t : * 

r hy Tl : Kl — > K2 r hy T2 I Kl 

r hy ri r 2 : K2 



Ty.TyFam 



Ty_Ground 



Ty_Arrow 



Ty_Forall 



Ty_App 



D. Proof of substitution lemma 

The kinding judgment for types, the proposition validity judgment, 
and the context validity judgments are all mutually recursive. They 
all support a standard substitution lemma, which we do not prove 
here: 

Lemma 20 (Type substitution). Assume T h y a : k. Then, the 
following are true: 

1. IfT, a:K, A hy T : K, then T, A[o/a] hy r[o/a] : K. 

2. 7/htx T, a-.K, A, then h ctx I\ A[o/a]. 

3. IfT, a:K, A \- prop (f> ok, then F, A[o/a] h pr0 p 4>[a/a] ok. 

Lemma (Co_ AxiOM Su bstitution [Lemma 15]). IfT,; A, p-.n, A' h co 
C[i] T : F(pi[r/ai]) ~ v^r/oa] and S;A hy o ■ K, 



then E; A, A'[a/P] h co C[i\ t[o//3] : F { Pi [r / ai\[a / p]) 

Vi\T/OLi\\alP\. 



Pr oof. W e invert T; A, f3:n, A' h co C[i] r : F( Pi [T/ai]) 
Vi[r/ai] to get the following: 

• C:* j^T, 

• * = [oTTt]. F(p) ~ u 

• E; A, /3-.K, A' hyT-.K, 

• htx E; A, /3:k, A' 

' Vj < i, no_conflict(*, i,T, j) 



Lemma 20 gives E; A, A'[o/P] h y r[a/fi] : K 8 andh ctx E; A, A'[a/P]. 
Let 4> = F(p) ~ u - It now remains only to show that Vj < 
i, no_conflict(*, i,t[o/ and (j>[r / a,][a / P] = 4>[r[a/P]/ai], 
and then we can use Co_AxiOM to get the desired result. 



Red 



C:* G E * = [oTk]. F(p) ~ u 

h gnd E t = pjfV'/ai] _ t' = Vi[i>/ai 
Vj < i, no_conflict(\l', i, V>, j) 
EhC[F(f)] -wC[r'] 

Figure 8. The type rewriting rule 



The second fact above is immediate from the fact that the vari- 
able P must not be free in 0, invoking the Barendregt variable con- 
vention and noting that p is introduced separately from any of the 
variables in scope in <j>. 

Thus, we must only show Vj < i, no_conflict(*, i, r[a/P], j). 
Thus, given j < i (and knowing no_conflict(>I', i,T,j)), we must 
show no_conflict(\l/, i, r[a/P],j). We proceed by case analysis on 
no_conflict(\l/, i, f, j): 



Case NC_Apart: We must show only that a part (ft- , pi [t[<t / p]/oti]), 
assuming apartfjoj". pi[r/ai]). The result is immediate after in- 
voking Property 12, with Q = P h->- a and noting that (3 cannot 
be free in p~l. 

Case NC_COMPATIBLE: We note that r appears nowhere else in 
the premises of this rule. Therefore, changing t has no effect, 
and we are done. 

□ 



E. Proof of consistency 

As described in Section 5.3, we use a rewrite relation, defined in 
Figure 8, show that it is complete with respect to E; A ho 7 : 
ti ~ T2, and then conclude that E must be consistent, as rewriting 
preserves non-type-family head forms. 

Type contexts Throughout this proof, we use a notion of type 
contexts, or types with holes. The notation C[-] denotes a type 
with exactly one hole in it. Similarly, C[-J denotes a type with any 
number of holes (possibly 0) in it. We generalize these definitions 
to lists, saying that (C [■] denotes a list of types with exactly one hole 
(in one specific type, not one hole per type) and that (C[-J denotes 
a list of types with any number of holes. 

E.l Rewrite relation 

The only form of reduction is type family simplification, using 
the same no_conflict judgment that appears in the Co_AxiOM 
rule. The use of C[] in the conclusion states that a type family 
application can reduce anywhere within the structure of a type. 
As C[-] denotes a type context with exactly one hole, only one 
type family reduction happens in one step. Note that this rule is 
nondeterministic . 

We use the notation E h <ri 02 to mean the reflexive, 
transitive closure of the relation E h • ~-> •. We write single-step 
joinability of cri and 02 as E h a\ <^> 02; this fact holds whenever 
there exists (73 such that E h ai ~* 0-3 and E h 02 ~+ 0-3, or 
E h (Ti ~» (72, or E h (72 ~+ ci, or 01 = 1T2. General joinability 
is written E h ai <4>* a 2', this fact holds whenever there exists 03 
such that E h (Ti (73 and E h 02 ~^>* 03. 

We generalize the relation to hold over lists of types, written 
E h t ~* a, to say that the list a is identical to the list r except for 
one element which takes one step. We also say Shr-^'ff, which 
is identical toEhr^'fr. 

Definition 21 (Confluence). Our rewrite system is confluent if, for 
all 00, <Ti, and 02 such that E h oq ai and E h (To ^* 02, 

E h (Tl <4>* (T2- 
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In order to show the completeness of the rewrite relation for 
transitivity coercions, we need to show the transitivity of the join- 
ability relation — that is, that E h o\ <4>* 01 and E h 02 <4>* 03 
implies E h a\ <4>* 03. This fact requires confluence of the rewrite 
system. 

E.2 Local confluence 

Newman's lemma (Newman 1942) states that a terminating rewrite 
system is confluent if it is locally confluent. 

Definition 22 (Local confluence). Our rewrite system is locally 
confluent if, for all ao, ffi, and 02 such that E h (To ^ (J\ and 
E h ao ~» a 2 , then E h ui 02. 

A diagrammatic presentation of different confluence properties 
is in Figure 6. 

Because we have assumed termination, we need only show local 
confluence to show confluence. As usual, we will need a small 
menagerie of supporting lemmas before we can get to the main 
proof. 

Lemma 23 (Stability of choice of substitution of lists). Ifr[a/a] — 
t[ct' /a] and all the a are free in r, then a = a'. 

Proof. By induction on the structure of r: 

Case r = a: It must be that a — a, a one-element list. Thus, we 
know that a = a and a' = a' . The given equality reduces to 
a — a', so we are done. 

Case r = (Ji — > (72 : Divide the variables a into three groups: 

• Pi are the variables free in 01 but not free in (72, 

• P2 are the variables free in er 2 but not free in <xi, and 

• /?3 are the variables free in both o\ and 02- 

Divide a and a' accordingly. Then, we can use the induction 
hypothesis to get that 07,03 = o-[,a' 3 and that 02, 03 = 
a 2 , cr' 3 . Thus, we can conclude that a = a' as desired. 

Cases r = VttiK.w, r = wi U2, and r = Similar. 

Case t — H: The list of variables a must be empty, as must be a 
and a', so we are done. 

□ 

Lemma 24 (Stability of choice of substitution of lists in lists). If 

r[a/a\ = t[o'/o\ and all the a are free inr, then a — a'. 

Proof. By induction on the length of r , appealing to Lemma 23 and 
using logic as above to manage the free variables. □ 

Lemma 25 (One step/one hole context substitution). //S h t ^ 

r',thenT,\-C[r] ~+ C[t']. 

Proof. Straightforward induction on the structure of C[-]. □ 

Lemma 26 (One step/many holes context substitution). // E h 

r ~» t', then E h C[t] ^* C[t']. 

Prao/ Straightforward induction on the structure of C[-J. □ 

Lemma 27 (Multistep/many holes context substitution). // E h 

r ~»* r', then E h C[t] ^* C[r']. 

Proo/ Straightforward induction on the length of the reduction 
E h r t', appealing to Lemma 26. □ 

Lemma 28 (One step/one variable substitution). // E h r r', 

?/ie;j E h <t[t/q] a[r' /a]. 

Proof. By Lemma 25. □ 



Lemma 29 (One step/list of variables substitution). //E h r ~» r', 

f/zen E h o-[t/q] ct[t' /a]. 

Proof. Straightforward induction on the list r, using Lemma 28. 

□ 

Lemma 30 (Multistep/list of variables substitution). //Eh 
t t', then E h crfr/a] ^* crfr'/a]. 

Proo/ Straightforward induction on the length of the reduction 
E hrVr', appealing to Lemma 29. □ 

Lemma 31 (One step linear type pattern anti-substitution). If a is 

the set of free variables in linear pattern p and E h p[a/a] 
p[a' /a], then E h a a'. 

Proof. By induction on the structure of p, where the linearity as- 
sumption is needed when dividing up the variables and combining 
the results when appealing to multiple induction hypotheses. □ 

Lemma 32 (Multistep linear type pattern anti-substitution). If a is 

the set of free variables in linear pattern p andYl h p[a/a] p[a'/a], 
then E h a'. 

Proof. By induction on the length of the reduction E h p\a /a] p[a' / 
appealing to Lemma 3 1 in the inductive case and Lemma 23 in the 
base case. □ 

Lemma 33 (Multistep type pattern anti-substitution). If a is the 

set of free variables in pattern p and E h p[o / a] p[a' /a], then 

Proof. Let p' be the result of replacing all variables in p with fresh 
variables. Thus p' is a linearized version of p. Let the set of free 
variables in p' be a'. We can see that for some list of types ip, 
p[cr/a] — p'[tp/a']. (The list of types tp is just like a but with some 
repetitions to account for the linearization.) Similarly, we have 
p[a'/a] = p'[i>'/a']. Thus, we know E h p'[tp/a'] p'[tp'/a']. 
We then appeal to Lemma 32 to get E h ip~>* ip'. Recall that 
this notation means that E h ip tp'. Thus, we can conclude that 
E h a a' (because each and ip' has an equal a or a') and 
then E h a~^* o 7 . □ 

Lemma 34 (Local confluence). // Good E, the rewrite relation 
E h • ~» • is locally confluent. 

Proof. We assume E h o~o ~* a\ and Ehao w cr 2 and we must 
find (73 such that E h o\ 03 and E h 02 03. We proceed 
by induction on the structure of a () . 

Case (7o = Ti — > T2 : Inverting E h oo ~^ fi and E h do 02 
tells us that (n T2) = Ci[Fi(V'i)] and (n — > r 2 ) = 
C 2 [F 2 ( ; 02")], with (7i = Ci[V>i] and ct 2 = £2^2]- We now do 
case analysis on C\ [■] and C2 [•] : 

CaseCi[-] =Ci[-} ^ t 2 ,C 2 {-] =C 2 [-] -»■ r 2 : Note that C([Fi(^)] 
Ti = C 2 [i ;i 2(i/'2)]- Therefore, using the other conditions 
known from inverting the original steps from (7o, we know 
that E h r\ ~^ rn and E h n ^* T12, where m = C( [V'i] 
and ri2 = C^IV'i]- Use the induction hypothesis to get T13 
such that E h th ^* T13 and E h ri2 ^* T13. Then, by 
Lemma 27 to lift this result back to r\ — > T2, we are done, 
showing that (73 = T13 — ¥ T2. 

CaseC[-] = €[[■} -> r 2 ,C 2 [-] = n -> C 2 [-]: Let r{ = C([Vi] 
and T2 = C 2 [i/ , 2]- Then, oi = r{ — > T2 and 02 = r\ — > t? 2 
with E h n ~^ r{ and E h T2 ~^ t 2 . We let 0-3 = r{ — >• r2, 
and we are done. 
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Other cases: Similar to the cases above. 

Case (To =Va:K.r: Similar to the case for t\ — > r 2 . 

Case (T 0 = t\ T2l Similar to the case for t\ — > T2. 

Case cr 0 = F(v): Inverting S h ao ~-» a\ and E h ao ~> o"2 
gives us a 0 = C'[F'(r)] and a 0 = C^'p 7 )]. If C'[-] + ■ 
and C"[-] / •, then we are in a case similar to the case for 
ti — > T2, and we simply use induction. Otherwise, we are left 
with three cases: 

CaseC'M = F (&[■]), C"[-] = ■: In this case, v = <E[F'(t)\. 
Let r' be the top-level reduct of F'(r). Thus, o\ = 
F((C[r']).Let^7 = (E[T']. 

We also know that E h F(v) ~-> 1T2 by a top level reduction. 
Inverting gives us the following: 

• C:*_€_E 

• * = [ma]. F(p) ~ a' 

• w = p, [V Voj] 

• cr 2 = 0i[V/a«] 

• Vj < i, no_conflict(*I', i, ip, j) 

We want to find a common reduct of 02 (which might not 
be headed by F) and F(v'). Thus, we must find a way to 
reduce F(y') at the top level. We now use Property 14 to 
get v 77 such that E h v 7 ^* Tj 77 , v 77 = SI' (pi) for some SI' , 
and for every p' such that apart(p', v), apart(p', v"). 
Instead of reducing F(v') directly, we step F(v') to F(v") 
(getting E h F(v') F(v") from repeated application 
of Lemma 27) and then show that F(v") can reduce at the 
top level by the same equation at F(v) reduced to form cr 2 - 

Thus, we must prove that v" = pi[ip'/ai] (for some ip') 
and that, for all j < i, no_conflict(*, i,tp',j). 
We know that v" = Sl'fjn). We also know that, by assump- 
tion, the free variables in v" are distinct from the free vari- 
ables in ~pl. Thus, SI' must map every free variable in ~pi to 

some other type. Thus, we have v" = pi [tp'/oii] for the ip' 
taken from the range of Si'. 

We then perform inversion on the known facts that, for all 
j < i, no_conflict(v|/, i, ip,j). We now fix j, and repeat this 
argument for all j < i: 



Case NC_Apart: We see that apart(p.,, pi[ip/cti]). From 

Property 14, we see that a part (pj, pi[ip'/oci]) as desired. 
Case NC.Compatible: The check compat(*[i], *[;']) 
does not depend on the types tp or if)', and thus we are 
done. 



Thus, F(v") reduces at the top level to 0-3 = a'i[ip' /<Xi\. 
It remains to show that (T2 (which equals a'i[ip / oti\), the 
initial top-level reduct of F(v) reduces to 0-3. We know that 

E h pi[ip/ai] pt[tp' /cti]. Thus, by repeated application 
of Lemma 33 (and appealing to clause 2 of Good to show 
that every ip € ip is considered), we get Shi/: ip' . By 
Lemma 30, we can conclude E h a'^ip/ai] a'i[ip' /a;], 
as desired. 

CaseC'M = •>£"[•] = F((C"[-]): Similar to the case above. 

CaseC'[-] = = ■: We will show a stronger property 

than local confluence in this case; we will show that if 
E h F(t) ~» vi and E h F(t) ~> 1)2, both at the top 
level, then vi = V2. 

We invert both reductions to get the following facts, along 
with h| n d E: 



from E h F(t) ^ di 


from E h F(t) — ♦ V2 


Ci:*i € S 


C 2 :*2 £ E 


*i = [ai:«i]. F(pi) ~ 


*2 = [a 2 :K2\. F(p 2 ) ~ <r 2 


r = piilV'i/aii] 


r = p 2j [i/' 2 /a 2j ] 


Wl = (T l8 [Vl/ a l>] 


"2 = cr' 2 j[ip2/a2j] 


Vfc < i, 


Vfc < j, _ 


no_conflict(>]/i, i, tpi, k) 


no_conflict(*2, j, V"2, fc) 



Thus, we must show that a[ i [i/>i ja\ »] = (T 2j [i/^/o^j]. 
From clause 3 of Good, we see that either i = j = 0 (open 
family) or Ci = C2 (closed family). We will tackle these 
cases separately: 



Open family: In this case, the axioms Ci and C2 have 
one equation each and thus we simply drop the i and j 
subscripts. Let <2>i and $2 be the the equations of Ci and 
C2, respectively. 

We know from the inversions that pi[-0i/ai] = P2[ip2/ct2\- 
Let SI2 = [0.1 1 — y ipi , ck 2 !-> V^]- We can see that ^2 is a 
unifier of pi and 7^2. Then, clause 4 of Good tells us that 
compat($i, $2)- Here, we have two cases: 
Case CompatXoincident: We know that SI is a most 
general unifier of pT and p2 (appealing to Property 11) 
and Q(tri) = Sl(a' 2 ). Thus, there must be some SI' such 

that Sl 2 = SI' o fi. 

We must show that cr[ [ipi /cti] = a'2[ip2/a 2 ]. This 
equation is equivalent to SI2 (<ri) = ^2 (cr 2 ), which in 
turn is f2'(fi(iri)) = Si' (Sl(a' 2 )). But, we know that 
Sl(a[) = 51((T2), so we are done. 
Case COMPAT_DlSTINCT: We know that unify(pl,p2") fails. 
Yet, we have fi 2 as a unifier of these types. Appealing to 
Property 40, we have a contradiction, and thus this case 
cannot happen. 

Closed family: We know Ci = C2 and, by h gnd E, there 
can be only one axiom of the same name in the context, so 
*i = *2, and thus we can drop the 1 and 2 subscripts, 
except on the V, which do not appear in the axiom types. 
Thus, we must show a'i[ipi/ai] = a'jlfo/aij]. 
Now, we must examine the indices i and j. If i = j, 
then we are done by an application of Lemma 24, using 

p[ipi/a] = p[ip2/a] and clause 2 of Good. So, we as- 
sume, without loss of generality, that i > j. Inverting 
no_conflict('I>, i,ipi,j) leads us to three cases: 

Case NC_APART: We see here that apart(/J7, pi[ipi/ai]). 
Yet, we know from the original inversions that pi [-01 /cti] — 

pj [ifa/aij]. The substitution [ctj *-¥ ^2] is then a unifier 
of the two types that we know are apart, leading to a 
contradiction, appealing to Property 13. Thus, this case 
cannot happen. 
Case NC_Compatible/Compat_Coincident: Here, 
we know that SI is a most general unifier (appealing to 
Property 11) for p7 and pj and that Sl(a' i ) — Sl(cr'A. 

From the original inversions, we know pi[ipi/ai] = 

pj [ipz/aij]. Let SI2 = [m h-> ipi, aj >-¥ 1P2]. We can say 
SI2 = SI' o SI for some SI' . We can rewrite our goal as 
showing that Sl'(Sl(a' t )) = Si' (Slier-)) . This is imme- 
diate from the fact that Sl(a'i) = £7 (crj ) , and so we are 
done. 

Case NC Compatible/Compat Distinct: We know 
un 'fyoo (P* j Pi) f^l 8 - Yet, we know from the original in- 
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versions that Pi[ipi/cti] — pj[ip2 / otf]. The substitution 
[aj <-¥ ipi , ctj h-> ^2] is then a unifier of p7 and pj, lead- 
ing to a contradiction, appealing to Property 1 1 . 

□ 

Lemma 35 (Confluence of terminating systems). If Good E and 
Sh'-^'ijfl terminating rewrite relation, then it is confluent. 

Proof. By appealing to Newman's lemma (Newman 1942) and 
Lemma 34. □ 

E. 3 From confluence to consistency 

Lemma 36 (Transitivity). If E h • ~> • is a terminating rewrite 
relation, Good S, S h n <4>* T2 and S h T2 <4>* T3, then E h 
Ti r 3 . 

Proof. By Lemma 35. □ 

Lemma 37 (Congruence). //E h n ^* r 2 , then E h C[tJ C[t 2 ]]. 

Prao/ By appealing to Lemma 27. □ 

Lemma 38 (Completeness). IfE\--~*-isa terminating rewrite 
relation, Good E and E; A h co 7 : o\ ~ CT2, f/iew E h <n tT2. 

Prao/ We proceed by induction on E; A \- co 7 : cti ~ 02: 

Cases Co Arrow, Co Forall, Co App, and Co TyFam: 

By the induction hypothesis, appealing to Lemma 37 and 
Lemma 36. 

Cases Co_Refl, Co_Sym, and Co_Trans: From the fact that 
E h • ■ is an equivalence relation, appealing to Lemma 36. 

Cases Co LEFT and Co RIGHT: The induction hypothesis gives 
us that E h Ti r 2 <4>* d ct 2 . We can see that any reduct of a type 
application must also be a type application. Thus, the common 
reduct must be vi w 2 (for some v\ and V2) where v\ joins t\ 
and <n and 1)2 joins T2 and 02. Thus, we are done. 

Case CO_AxiOM: From claus e 1 of G ood and the Co.AxiOM 
rule, we know that ai = F(vi[p/cti]) and that 01 =v' i [p/a i }. 
We conclude that E h o\ ~* 02, as the premises of the rule 
RED are all given by the premises of the rule Co_AxiOM. 

□ 

Lemma 39 (Consistency). If E h • ~» • is a terminating rewrite 
relation and Good E, then E is consistent. 

Proof. A consistent coercion equates two types with the same 
ground head forms. By Lemma 38, these two types must be join- 
able under the rewrite relation. Yet, the rewriting rule preserves 
all head forms except for type families. As type families are not 
ground head forms, we are done. □ 

F. Proof of properties of apart 

This appendix includes the proofs that our concrete definition of 
apart, as given in Definition 6, satisfies the properties stated in 
Section 5.1. Then, we show that these properties, along with the as- 
sumption of termination, imply the high-level (sanity-check) prop- 
erties from Section 3.2. It is well-founded to use our confluence 
result for these later proofs as those properties are not used any- 
where in other proofs — they simply serve as a higher-level check 
on our formal results. 



F.l Proofs of Properties 12-14 

We restate our implementation of apart: 

Definition (Apartness [Definition 6]). 
apart(p,r) = -n U nify^(p, flatten(r)) 

Recall that flatten (Definition 5) replaces all type family appli- 
cations in a (finite) type with fresh variables, maximally preserving 
sharing. That is, flattening the same type family application twice 
in the same type (or list of types) converts both applications to the 
same fresh variable. In order for flatten to be a well-defined func- 
tion, it must refer to a mapping from every possible type headed by 
a type family to fresh variables. This mapping is countably infinite, 
but we can assume, as usual, a countably infinite set of fresh vari- 
ables. Furthermore, we assume that the set of variables in the range 
of this mapping is distinct from variables used elsewhere (partic- 
ularly, in patterns). If this assumption is violated for some use of 
flatten, we simply rename the variables accordingly. 

The above definition of flattening with respect to an infinite 
mapping of type families to variables, means that flattening com- 
mutes with type constructors. For example, flatten (n — > T2) = 
flatten(n) -> flatten(r 2 ). 

For completeness, we also restate the correctness of unification, 
but now for unify oc . 

Property 40 (unify ^ correct). If and only if there exists a substi- 
tution uj ( whose range may include infinite types ) such that cj (a) = 
U)(t), then unify^a, r) succeeds, returning bj. Furthermore, u> is 
a most general unifier of a and f. 

Before getting to the properties themselves, we must prove 
some properties about flatten. First, we extend flatten to apply to 
substitutions and define an inverse operation: 

Definition 41 (Flattening a substitution). If Q, — [aTTf], we 
say flatten(fi) for [a H> flatten(r)], where sharing is maximally 
preserved between the different types r. 

Definition 42 (Inverse flattening). We let flatten -1 denote the 
inverse operation to flattening, implemented by doing a reverse 
lookup in the map from type family applications to variables. 

Note that flatten -1 is a substitution, infinite in extent, but or- 
dinary in other respects. In particular, note that the elements in the 
range of flatten -1 are finite — that is, flatten -1 could be denoted 
by the metavariable 57. 

Lemma 43 (Flattened substitutions). For all type patterns p and 
substitutions Q,, flatten(fi(p)) = (flatten(fi))(p). 

Proof. The pattern p contains no type families, so flatten does not 
affect the parts of p unchanged by the application of Q. Because 
flatten preserves maximal sharing, it must be the case that apply- 
ing a flattened substitution yields the same result as flattening an 
substituted pattern. This can be shown by straightforward induc- 
tion on p. □ 

Lemma 44 (Flattening commutes with substitution). For all 

fi, there exists an Q! such that, for all t, flatten(fi(r)) = 
n'(flatten(r)). 

Proof. We can say that 

flatten(fi(r)) = flatten(ft(flatten -1 (fiatten(Y)))) 

Because flatten -1 is a substitution, and appealing to Lemma 43 
(noting that flatten(r) is a pattern), we can rewrite this as flatten(f2o 
flatten -1 )(flatten(r)). Thus, we let Q' be the substitution flatten(fio 
flatten -1 ) and we are done. □ 
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Lemma 45 (Flattening a list commutes with substitution). For 
all Q,, there exists an Cl' such that, for all f, flatten(fi(r)) = 
fi'(flatten(r)). 

Proof. By induction on the length of the list, appealing to Lemma 44. 

□ 

Property (Apartness is stable under type substitution [Prop- 
erty 12]). 7jfapart(p, t), then for all substitutions Q, apart(p, 0(t)). 

Proof. Expanding definitions, we must show that 
^unify^Qo, flatten(r)) 

implies 

-unif yoo (p,flatten(«(r))). 

We prove the contrapositive, that is, that unify ^ (p, flatten(f2(r))) 
implies unify^p, flatten (t)). Thus, we have a substitution w 
such that <jj(p) = w(flatten(fi(r))) and must find a lu' such that 
w'(p) = J (flatten (r)). 

By Lemma 45, we can say flatten(fi(r)) = fl' (flatten (r)) for 
some Q' . Then, choose u' — oj o fl'. We can see that u/(p) = 
uj' (flatten (r)) (noting that the variables in p are fresh from those 
in flatten (r)) as desired. □ 

Property (No unifiers for apart types [Property 13]). //"apart(p, r), 
then there exists no substitution ft such that H(p) = fl(r ). 

Proof. Expanding definitions, we must show that ^unify(p, flatten(f )) 
implies ^unify(p, r). We will show the contrapositive. Thus, we 
assume Q. such that fi(p) = Q(r) and we must find fl' such that 
fi'(p) = n' (flatten (r)). 

Choose O' = do flatten -1 . Because the free variables in p 
are distinct from the variables in the domain of flatten -1 , we have 
fi'(p) = Q(p). We also have 

fi' (flatten (r)) = ^flatten -1 (flatten(r))) = Q(t) 

and we are done. □ 

Property (Apartness can be regained after reduction [Property 14]). 

Iff = fl{p) and SI-t-»t', then there exists a t" such that 

1. Eh?-!*? 7 , 

2. t" = ft' (p) for some fl', and 

3. for every p' such that apart(p', t): apart(p', r"). 

Proof. We know that r matches some pattern p and that one el- 
ement in t steps, forming r'. Suppose that one element is r^. 
Thus, E h ~-> r' k . Inverting this step relation gives us that 
Tk — C[F(v)] and r' k = C[v'\, where F(v) reduces to v' at the 
top level. 

Define (£[•] to be the list of types r such that every occurrence 
of F(v) is replaced by ■. Thus, (C[.F(v)] = r. We choose r" 
(from the statement of the property) to be (E[t/]. We must show 
the following: 

• E h t' t": Straightforward application of the rule RED. 

• t" = fi'(p) for some Q': Because p cannot contain type fami- 
lies, it must be that maps some variables to types containing 
F(v). Choose Q,' to be SI with all occurrences of F(v) replaced 
by v' . Because all occurrences of F(v) in r have been replaced 
by v' , we can see that fi'(p) must be r". 

• For every p' such that apart(p',r), we have apart(p', r"): 
Assume we have p' such that apart(p',r). Unfolding defi- 
nitions (and taking the contrapositive) gives us u such that 
w(p') = ti;(flatten(r")), and we must find w' such that 
w '(p7) = w '(flatten(T)). 



Let a be the variable mapped from F (v) . Thus, f I atten (F (v) ) = 
a. Let do = [a H i/] and choose ui' = u: o f2 0 . Noting that 
a does not appear in p', we see that w'(p') = w(p'). Now, we 
must only show that a/(flatten(r)) = a;(flatten(r")). By our 
choice of a/, we know cj' (flatten (r)) = cj(f2 0 (fl a tten(r))), 
thus we must show Qo (flatten (t)) = flatten(r"). By its def- 
inition, flatten takes all occurrences of F(v) in r to a. Then, 
Slo takes all of these occurrences of a to v' . Since the only 
difference between r and r" is that all occurrences of F(v) 
are replaced by v' , we can see that Qo (flatten (r)) is indeed 
flatten(r"), and we are done. 

□ 

F.2 Proofs of Properties 2 and 4 

Property (Apartness through substitution [Property 2]). //apart(p, r) 
then there exists no f2 such that match(p, £1(t)). 

Proof. We shall prove by contradiction: assume £1 and Q' such 
that fi'(p) = H(t). We can simplify a bit and combine these 
substitutions, because the free variables of p are distinct from those 
in r; we can say fio(p) = ^o(t). Then, this is a contradiction, 
appealing to Property 13, and we are done. □ 

The next property (Property 4) requires an important auxiliary 
lemma. 

Lemma 46 (Matching can be regained after reduction). If Good E 

and E h f2(p) ~>* r rten ffere exi'sfs aw O' ^wcn f«af E h 

*n'(p). 

Ptoo/ Throughout this proof, we will consider types as abstract 
syntax trees. We will use "type" and "tree" interchangeably. 

Define the operation linearize to take a pattern and freshen all 
the type variables therein, thus producing a linear pattern. Our first 
step is to show that r matches linearize(p). How does fi(p) step to 
t ? It must be through a series of type family reductions. Because 
p does not mention type families, these type families must occur 
in fl(p) at or beneath where variables appear in the tree p. Thus, 
as fi(p) steps, the tree structure imposed by p does not change. 
However, it is possible that a type family application, say F(v) 
steps in two different ways throughout the tree fi(p) as f2(p) is 
reducing. Thus, we can claim only that r matches linearize(p), not 
p itself. 

When comparing the trees r and p, define a mismatch to be two 
locations in the respective trees where p has a repeated variable 
and t has two different sub-trees. Count only those matches that 
involve the left-most occurrence of a variable in p. We proceed by 
induction on the number of mismatches between p and r. 

Base case: If there are no mismatches, then we know that p must 
match r with a substitution SI'. We are done. 

Inductive case: Choose the left-most mismatch. Say that the re- 
peated variable in p is a and the disagreeing types in r 
are ai and 02. We know that E h f2(p) r, and thus 
that E h Q(a) a 1 and S h Q(a)^*o~2- By conflu- 
ence (Lemma 35), we know that there exists a 03 such that 
E h <7i -v** (73 and E h <72 ~>* 1T3. Let r' be r, except that 
both o\ and 02 in r are replaced by 0-3 in r'. We know that 
E h t~>* t' by congruence of the rewrite relation and thus 
that E h Q(p) ~>* t'. Thus, we can use the induction hypoth- 
esis to get CI' such that E h r' O'(p). Then, by transitivity 
of E h ■ •, we are done. 

□ 
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Lemma 47 (Matching normal forms). // Good E and E h 

fi(p)~>* v where v is a normal form, then there exists Q! such 
thatv = Q'(p). 

Proof. We apply Lemma 46 to see that there exists an f2' such 
that E h v Vl'(p). But, we know that v cannot step, and thus 
v = n'(p). □ 

Lemma 48 (Longest reduction). Suppose Good E. For every type 
T and its normal form v (whose uniqueness is guaranteed by the 
combination of confluence and termination), there exists a number 
n such that all reductions from r to v are of length at most n. 

Proof. Konig's lemma states that every tree with infinitely many 
vertices, each having finite degree, has at least one infinite simple 
path. Here, we are considering trees of reductions, rooted at r. 
We will use the contrapositive of Konig's lemma: that if every 
node in a tree has finite degree and all simple paths are finite, 
then there are finitely many vertices. For any type a, there are 
finitely many types a' such that E h a ~* a', because there 
are finitely many locations within a that can be headed by a type 
family and finitely many equations that type family application 
might match. By termination, we know all simple paths in the tree 
of reductions are finite. Thus, the contrapositive of Konig's lemma 
tells us that the tree has a finite number of nodes. Thus, we can 
simply enumerate all paths from r to v to discover the one with the 
longest path. This path's length is our result n. □ 

Lemma 49 (Apartness and normal forms). If apart(p, r) and E h 
t v where v is a normal form, then apart(p, v). 

Proof. Let the longest path from r to v be of length n (Lemma 48). 
We perform induction on n. 

Base case: Trivial. 

Inductive case: We know that r can step to some r'; that is, 
E h r t' . We then appeal to Property 14 (choosing 
p — flatten(r), but the choice is irrelevant) to get r" such 
that E h t' t" and apart(p, r"). By our assumption that 
n is the length of the longest path from t to v and the fact that 
E h r~>* t" by at least one step, we know that the longest 
path from t" to v has length less than n. Thus, we can use the 
induction hypothesis, and we are done. 



□ 



Lemma 50 (Apartness implies no match). If apart(p, r), then 
^match(p, r). 



G. Proof of compatibility soundness 

In this appendix, we show that the concrete implementation of 
compatibility (Definition 8) satisfies the definition of compatibility 
(Property 7). We use the implementation of compatibility included 
in our formal inference rules, as it separates Definition 8 into its 
two cases: 



compat($i, $2) Equation compatibility 



$1 = [oTTTtT]. -F(pT) ~ vi 
$2 = [0.2:^2]. F(p~2) ~ v 2 
unify(pT,p2) = O 
fi(vi) = n(v 2 ) 

compat(<E>i, $2) 
$1 = [oTTkT]. F(pT) ~ 

$2 = [Q2:K2]. F(p2) ~ V2 

unify (pT, P2) fails 



Compat .Coincident 



COMPAT.DlSTINCT 



compat(<l>i, <E> 2 ) 

We generalize Property 7 to work with unify^. 

Property 51 (Compatibility (with infinite unification)). Two type- 
family equations p and q are compatible iff ui\(lhs p ) = u>2(lhs q ) 
implies to 1 (rhs p ) = LU2(rhs q ). 

Proof. For all type family equations $1 and <E>2, where $1 = 
[oTTki]. F(pi) ~ vi and $2 = [02^2]- F(p~2~) ~ V2, we must 
show that compat($i , $2) implies that, for all wi and CJ2 such that 
wi (pT) = ^2 (p2 ) , it is the case that uj\ (v\ ) = UI2 (f2 ) . 
We have two cases: 

Case Compat.Coincident: Here, we know that w(pT) = 
lo(j>2) and, by Property 40, that w is a most general uni- 
fier. We further know that cu(vi) = u(v2). By assumption, 
wi(pl) = W2(p~2"). By the assumption that all patterns in type 
families have distinct variables, we know that the domains of wi 
and LU2 are distinct. Thus, we can write uj 1 = wi U 0J2, and say 
uj' '(pi) = cj'(p2). Similarly, we can say that we wish to show 
to'(vi) = uj'(v2). Because uj is a most general unifier, we can 
say that <J = uj" o u for some uj" . Thus, we wish to show 
uj" (uj(vi)) = uj"(uj(v2)). But, we know that w(wi) = ui{v2) 
so we are done. 

Case COMPAT .DISTINCT: Here, we know that there exists no uj 
such that cj(pT) = uj(p2). Yet, we have assumed that uji (pi) = 
^2(752) and by an argument similar to the last case, we can 
combine uj\ and UJ2 to uj' . This substitution uj is then a unifier, 
leading to a contradiction. 

□ 



Proof. We prove by contradiction. Assume f2 such that fi(p) = r. 
By the assumption that pattern variables are fresh, we can say 
fi(p) = n(r). Then, by Property 13, we have a contradiction. □ 



Property (Apartness through reduction and substitution [Prop- 
erty 4]). // apart(p, r), then for any r' such that r t': 
^match(p, t'). 



Proof. Let v be the unique normal form of r. By Lemma 49, 
we know apart(p, v). By Lemma 50, ^match(p, v). Note that 
the uniqueness of normal forms, we know E h t' v. By 
the contrapositive of Lemma 47, we see that -imatch(p, r') as 
desired. □ 
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